仕様2_PHPチュートリアル

If then Else フォーマット レイアウト これはプログラマによって決定されます。ブレースのスタイルが異なると、外観も若干異なります。一般的な方法は次のとおりです。 if (条件 1) // コメント { } else if (条件 2) // コメント { } else // コメント { } else if ステートメントを使用する場合、通常は else ブロックを使用するのが最善です。他の未処理の状況を処理するために使用します。可能であれば、else にアクションがない場合でも、else にレコード情報のコメントを入れてください。 条件付き書式設定では、常に等号/不等号の左側に定数が配置されます。例: if ( 6 == $errorNum ) ... 理由の 1 つは、数式で等号を省略すると、構文チェッカーがレポートを行うためです。あなたにとってはエラーです。 2 番目の理由は、式の最後で値を見つけるのではなく、すぐに値を見つけられることです。この形式に慣れるまで少し時間がかかりますが、非常にうまく機能します。 -------------------------------------------------- ----------------------------- switch 形式 case ステートメントから次の case ステートメントへのフォールドは、次の場合に限り許可されます。コメントが含まれています。デフォルトのケースは常に存在する必要があり、到達する必要はありませんが、到達するとエラーがトリガーされます。 変数を作成する場合は、すべてのコードをブロックに入れます。 たとえば、 switch (...) { case 1: ... // FALL THROUGH case 2: { $v = get_week_number() ... } デフォルト: } ----------- -------------------------------------------------- - ------------------ continue、break、? の使用: Continue と Break Continue と Break は、実際には隠れた goto メソッドであり、隠れています。 Continue と Break は goto と似ており、コード内で魔法のような働きをするため、使用は控えめに (可能な限り少なくして) ください。 この単純な魔法を使用すると、読者は何らかの理由で神だけが知っている場所に誘導されます。 Continue には 2 つの主な問題があります。1 つはテスト条件を回避する可能性があることです。 等式/不等式式をバイパスできます。 次の例を見て、どこで問題が発生するかを検討してください。 while (TRUE) { ... // 大量のコード ... if (/* 何らかの条件 */) { continue; code ... if ( $i++ > STOP_VALUE) Break; } 注: プログラマがエラーを簡単に見つけられないように、「大量のコード」が必要です。 上記の例から、さらなるルールを導き出すことができます。「Continue と Break を混ぜることは、災害を引き起こす正しい方法である」ということです。 ?: 問題は、人々は ? と : の間に多くのコードを詰め込もうとする傾向があることです。以下に、リンクに関する明確なルールをいくつか示します。 条件を括弧で囲んで、コードの残りの部分から分離します。 可能であれば、アクションには単純な関数を使用できます。 アクション、「?」、および「:」は、明らかに同じ行に配置できない場合は、別の行に配置します。 例: (条件) funct1() : func2(); または (条件) 長いステートメント : 別の長いステートメント ----------------------- ------------------------------------------------- - ---- 宣言ブロックの配置 宣言コード ブロックは整列する必要があります。 正当化は明らかです。 変数初期化のための同様のコード ブロックがリストされるはずです。 ??トークンは名前ではなくタイプに隣接する必要があります。たとえば、 var $mDate var& $mrDate var& $mrName var $mrDate = NULL; -------------------------------------------------- - ---------------------------- 1 行に 1 つのステートメント ステートメントが密接に関連している場合を除き、1 行に 1 つのステートメントのみを記述します。 -------------------------------------------------- ------------------------ 短いメソッド コードは 1 ページに制限する必要があります。 理論的根拠 この考え方は、各メソッドが個別の目的を達成する手法を表すというものです。 無効な引数が多すぎるのは、長期的には間違いです。 関数を呼び出すと、まったく呼び出さないよりも遅くなりますが、この決定には慎重な検討が必要です (時期尚早の最適化を参照)。 -------------------------------------------------- ------------------------ 明確にするために、すべての空のステートメントを記録します。for または while の空のブロック ステートメントは常に記録します。このコード部分が欠落しているか、意図的に記述されませんでした。 while ($dest++ = $src++); // VOID -------------------------------------- -------- --------------------------------------ゼロ以外のテストにデフォルトの方法を使用しないでください。 ゼロ以外の値のテストにデフォルト値を使用しないでください。つまり、 if (FAIL != f()) の方が次の方法よりも優れています。 if (f( )) FAIL にも値 0 が含まれる可能性があり、PHP はこれを false と見なします。失敗時の戻り値として 0 ではなく -1 を使用することにした場合は、明示的なテストが役立ちます。比較値が変わらない場合でも、明示的な比較を使用する必要があります。たとえば、if (!($bufsize % strlen($str))) は次のように記述します。 if (($bufsize % strlen($str)) == 0) テストを表す数値型 (ブール型ではない)。よくある問題は、strcmp を使用して文字方程式をテストし、その結果がデフォルト値と等しくなることがないことです。 ゼロ以外のテストはデフォルト値に基づいているため、他の関数または式には次の制限が適用されます。それらは失敗を示す 0 のみを返すことができ、他の値を持つことはできません。 真の戻り値が明確にわかるように名前が付けられており、Checkvalid() の代わりに関数 IsValid() を呼び出します。-------------------------------------------------- ------------------------ ブール論理タイプのほとんどの関数は、FALSE の場合に 0 を返しますが、ゼロ以外の値が使用されると、それはTRUE なので、等価 1 (TRUE、YES など) のブール値をテストする代わりに、等価 0 (FALSE、NO など) を使用します。 if (TRUE == func()) { .. . は次のように記述する必要があります: if (FALSE != func()) { ... ----------------------------- ---------------------------------------------------- ------ 通常は埋め込み代入を避ける 場合によっては、埋め込み代入ステートメントが見られることがありますが、これらの構造は冗長性が低く可読性が高く、優れた方法ではありません。 while ($a != ($c = getchar())) { 文字を処理する } ++ 演算子と -- 演算子は代入ステートメントに似ています。したがって、多くの目的で、関数を使用すると副作用が発生する可能性があります。埋め込み割り当てを使用すると、実行時のパフォーマンスを向上させることができます。いずれにせよ、プログラマは、埋め込み代入ステートメントを使用する場合、速度の向上と保守性の低下との間のトレードオフを考慮する必要があります。例: a = b + c; d = a + r; とは書かないでください。ただし、後者は 1 サイクルを節約します。しかし、長期的には、プログラムの保守コストが徐々に増加し、プログラム作成者がコードのことを徐々に忘れていくため、成熟期における最適化の効果は減少します。 -------------------------------------------------- ----------------------------- 自分や他の人の努力の成果を再利用する 共通の構造を持たないプロジェクト間で再利用する ほぼ不可能です。オブジェクトは既存のサービス要件に準拠します。プロセスが異なればサービス要件環境も異なるため、オブジェクトの再利用が困難になります。 共通の構造を開発するには、事前に多大な設計努力が必要です。理由が何であれ、努力がうまくいかないときは、いくつかの方法が推奨されます。 アドバイスを求めてください。グループにメールを送信して助けを求めてください。この単純な方法はめったに使用されません。なぜなら、プログラマーの中には、他人に助けを求めると自分が劣っていると思われると感じるからです。他人がやったことを何度も繰り返すのではなく、新しくて興味深い仕事をしてください。 何かのソース コードが必要な場合、誰かがすでに作成している場合は、グループにメールで支援を求めてください。その結果は驚くべきものになるでしょう！ 多くの大規模なグループでは、個人は他の人が何をしているのかまったくわからないことがよくあります。何かやるべきことを探していて、ボランティアでコードを書いてくれる人が見つかるかもしれません。人々が協力すれば、そこには常に金鉱が存在します。 教えて！何かをするときは、それをみんなに伝えてください。何かを再利用できるようにした場合は、他の人にも知らせてください。恥ずかしがらずに、自分のプライドを守るために自分の仕事を隠してはいけません。 自分の仕事を共有する習慣が身につくと、全員がより多くの成果を得ることができます。小さなライブラリを恐れない コードの再利用に関する一般的な問題は、人々が自分が作業したコードからライブラリを構築しないことです。再利用可能なクラスはプログラム ディレクトリに隠れている可能性があり、プログラマがクラスを分割してライブラリに追加しないため、決して共有されることはありません。 その理由の 1 つは、人々が小さな図書館を作ることを好まないこと、そして小さな図書館に対して間違った感情を抱いていることです。この感覚を克服してください。コンピューターはライブラリの数を気にしません。 再利用でき、既存のライブラリに入れることができないコードがある場合は、新しいライブラリを作成します。もし人々が再利用について真剣に考えているなら、図書館は長い間それほど小さいままではないでしょう。ライブラリが再構成または追加されたときにメイクファイルを更新する必要があるのが怖い場合は、メイクファイルにライブラリを含めずに、サービスのアイデアを含めてください。基本レベルの Makefile は、それぞれがライブラリのセットで構成されるサービスを定義します。より高いレベルの makefile は、必要なサービスを指定します。サービスのライブラリが変更される場合、下位レベルの Makefile のみを変更する必要があります。リポジトリを保持する ほとんどの企業は、自社がどのようなコードを持っているかを知りません。そして、ほとんどのプログラマーは依然として、自分が何をしたかを伝えたり、現在存在するものを尋ねたりしません。解決策は、利用可能なものをリポジトリに保存しておくことです。理想的な世界では、プログラマーは Web ページにアクセスし、パッケージ化されたライブラリのリストを参照または検索して、必要なものを取得できるようになります。プログラマーが自発的にそのようなシステムを保守するようなシステムをセットアップできれば、素晴らしいことです。再利用可能性の検出を担当する図書館員がいる場合は、さらに良いでしょう。もう 1 つのアプローチは、ソース コードからリポジトリを自動的に生成することです。これは、マニュアル ページやリポジトリ エントリとしても機能する共通のクラス、メソッド、ライブラリ、およびサブシステム ヘッダーを使用して行われます。 -------------------------------------------------- ---------------------------- 评价注释注释应该是讲述一故事 あなたのコメントはシステムを説明する物語であると考えてください。コメントはロボットによって抽出され、マニュアル ページに形成されることを期待してください。クラスのコメントはストーリーの一部であり、メソッド署名のコメントはストーリーの別の部分であり、メソッドの引数は別の部分であり、メソッドの実装はさらに別の部分です。これらすべての部分が組み合わされて、別の時点で、あなたが何をしたのか、そしてその理由を正確に他の人に知らせる必要があります。決定事項を文書化する コメントには決定事項を文書化する必要があります。あらゆる時点で、何を選択するか