ホームページ >バックエンド開発 >PHPチュートリアル >PHPコードを標準化する簡単な方法
簡単に言うと、コーディング標準は実際には次の 3 つの側面から構成されます:
およびその他の場所キーワードの大文字と小文字の区別や糖衣構文 (array() や [] など) の使用の問題など。私は以前に PSR 標準を整理し、php-cs-fixer のようなツールも探しました。これらはコードを標準化する重要な手段です。統一された標準があり、ツール検査を使用すれば、統一されたコーディング制約を形成することは難しい問題ではありません。
基準はありません。スペース、改行、名前付けに関しては、異なる人、または同じ人であっても非常に恣意的である可能性があります。コードが長いと、ファイル全体が非常に乱雑に見えます。
典型的な例は次のとおりです: if と else の組み合わせは、次のような無数のスタイルで記述できます:
<?php# 单语句不写大括号if (true) doSomething();# else 大括号换行 十分占篇幅if (true){ doSomething();}else { doElseThings();}# 此外还有关键字后不带空格,随意缩进等等# ...
別の例は、変数と関数の名前付けの問題であり、さまざまな組み合わせスタイルが際限なく出現します:
<?php# 全小写$someparam1 = null;# 首字母下环线$_some_param_1 = null;# 某些库的类,下划线和大小写混用class Abstract_ClassA{}
ここではありません さまざまな書き方の長所と短所について話し合いますが、スタイルは一貫性があり、混在してはなりません。
PSR 標準を注意深く見てみると、この標準ではカバーできない部分があることに気づくかもしれません。たとえば、非常に長い式をいつラップするか、どのようにインデントするかなどです。
ここに関係しているのは、コーディング習慣の制約です。
たとえば、特定のデータベース クエリのカプセル化など、メソッド呼び出しの連鎖の問題:
<?php# 不换行的情况下句子会很长$result = $this->db->select('id')->where('a', 1) ->groupBy('a')->orderBy('id', 'DESC')->result();# 这种情况下我建议是一个条件一行,保持缩进$result = $this->db->select('id') ->where('a', 1) ->groupBy('a') ->orderBy('id', 'DESC') ->result();
配列定義、一部の配列メンバー文字列が非常に長い場合の書き込みメソッドもあります:
<?php$array = ['abcdefg', 'acbdfeg', 'bcadgfe', 'cdadgef'];# 如果成员太长,我建议拆解,这样$array = [ 'abcdefg', 'acbdfeg', 'bcadgfe', 'cdadgef',];
コードを書くプロセスにおいて、最適な書き方とコーディングの習慣は同じではありません。ここでお話したいのは、PHP の言語機能やフレームワーク機能を踏襲し、言語やフレームワークの機能を最大限に活用して冗長性を軽減する方法についてです。
たとえば、フロントエンドによって渡されたパラメータを取得する場合、次のようなコードがよく見られます:
<?php$param = isset($_POST['param']) ? $_POST['param'] : '';
さらに、一部のフレームワークは、$this-> など、フロントエンドによって渡されたパラメータをカプセル化します。 ; request->data['param'] の場合、isset や array_key_exists を使って判断すると、パラメータを取得する文全体が非常に長くなります。
三項演算子を使用する場合、場合によっては?: を組み合わせることができることに注意する必要があります。
実際、ステートメント内で同じ変数が複数回出現するのを防ぐために、この記述メソッドをカプセル化する必要があります。デフォルト値を割り当てる場合は、フレームワークがカプセル化を提供しているかどうかを調査するか、強制的な型変換を実行できます。
もう 1 つの状況は、条件とループがネストされている場合です。たとえば、配列からフィールドを抽出したり、フィールドの値を処理したりする場合、array_map と参照 (&) をうまく利用すると、多くの場合、作業を大幅に節約できます。ただし、これを使用する場合は、配列ポインターの最後の位置にも注意する必要があります。
条件に基づいて結果を返す場合は、return を上手に活用する必要があります。合理的な抽象化とカプセル化もあります。
上記の問題に加えて、日常の開発で注意する必要があります。その後の作業もあります。
過去のコードを見て、もっと良い書き方があるのではないかと感じている人も多いと思います。時間が経つにつれて、私は常により豊かな経験とより多くのアイデアを得るでしょう。時々自分のコードを見直すことは過去の要約にもなり、新たな洞察が得られるかもしれません。
チームプロジェクトでは、コード全体の仕様においてチームメイトの協力が決定的な役割を果たします。チーム内に仕様に従わず、コードをあちこち変更しなければならない人が 1 人いると、すべての制約がすぐに破られてしまう可能性があります。
この作業は、統一された基準と適切な実行によってのみ完了できます。