PHP のコーディング標準を再投稿している人がいるかどうかはわかりませんが、今後の皆さんのコミュニケーションのために、コード形式を統一することは有益だと思います。どう思いますか?

エンコーディング|仕様

PHP コーディング標準
1. はじめに
1.1. 標準化の重要性**
標準化の問題は、ある面では誰もが同じ状況にあると感じさせます。これにより、多くのプロジェクトで推奨事項が進化し、多くの企業が何週間もかけて一字一句議論することになりました。標準化は特定の個人的なスタイルではなく、ローカルな変更を完全に受け入れます。
1.2. 利点
プロジェクトが公的標準に準拠しようとすると、次のような利点があります:
・プログラマーはあらゆるコードを理解し、プログラムのステータスを理解できます
・新人はすぐに環境に適応できます
・新たな接触を防止しますwith PHP 時間を節約する必要性から、人々は独自のスタイルを作成し、生涯にわたる習慣を身につけます
· PHP を初めて使用する人が何度も同じ間違いを犯すのを防ぎます
· 一貫した環境では、人々は間違いを犯す可能性を減らすことができます
· プログラマーには共通の敵がいる
1.3. デメリット
· PHP を知らない人が標準を作っているので、標準はバカに見えることが多い
· 標準が私が作っているものと違うので、標準はバカに見えることが多い。
・標準は創造性を低下させる
・長期間にわたって共同作業する人々には標準は不要です
・標準はあまりにも多くのフォーマットを強制します
1.4. 議論
多くのプロジェクトの経験から、プログラミング標準を採用することで、プロジェクトがよりスムーズに完了します。成功の鍵は標準ですか?もちろん違います。しかし、彼らは私たちを助けてくれるはずです。私たちはできる限りの助けを必要としています。正直に言うと、詳細規格に関する議論のほとんどは主に利己主義から生じています。技術的な完全性が欠けていると言える合理的な基準に関するいくつかの決定は、単なる好みの問題です。したがって、柔軟性を持ってエゴを抑制し、どんなプロジェクトもチームの努力に依存していることを忘れないでください。
1.5. 説明
1.5.1. 標準実装
まず第一に、その標準があなたの状況に十分に適していない可能性があることをすべて確認する必要があります。重要な論点がまとめられているかもしれないし、その中には強い反対意見もあったかもしれない。いずれにせよ、最終的に物事がうまくいけば、人々はその標準が合理的であることを理解できるほど成熟し、他のプログラマーもそれが合理的であると判断し、多少の留保はつきつつも安心してそれに従うようになるでしょう。自発的な協力がない場合は、要件を策定することができます。標準はコードでテストする必要があります。検討しなければ、この解決策は不正確さに基づく単なる笑えるものばかりです。
1.5.2. この意見に同意します
1. うまくいきません。しかし、それは非現実的で退屈です
4.まずはそれから。 5. そうあるべきです。
もしあなたがネガティブな偏見を持って物事を見るようになった場合は、広い心でいてください。それでも「くだらない」と結論付けることはできますが、そのためには、さまざまなアイデアを受け入れる必要があります。時間に余裕を持って取り組んでください。
1.5.3. プロジェクトの 4 つのフェーズ
1. データベース構造
3. ​​HTML レイヤー
2. 適切な名前付け

。古代人は、人の本当の名前を知ると、その人に対して信じられないほどの力が与えられると信じていました。物事に適切な名前を考えている限り、それはあなたとあなたの後に続く人たちに、コードよりも大きな力を与えるでしょう。笑うな！
その名前は、それが位置する生態環境における何かの長期的かつ広範囲にわたる結果です。一般に、システムを理解しているプログラマだけが、システムに最も適切な名前を思いつくことができます。すべての名前が自然に適切であれば、関係は明確であり、意味を推測することができ、一般の人々の推論が期待できます。
対応するオブジェクトに一致する名前が少数しかない場合は、デザインをもう一度よく見ることをお勧めします。

2.2. クラスの名前付け

· クラス (クラス) に名前を付ける前に、まずそれが何であるかを知る必要があります。クラス名が提供する手がかりに基づいてクラスが何であるかをまだ思い出せない場合は、設計が十分ではありません。
· 3 つ以上の単語で構成される名前が混在していると、システム内のさまざまなエンティティ間で混乱が生じやすくなります。設計を確認し、(CRC セッション カード) を使用して、その名前に対応するエンティティに非常に多くの機能があるかどうかを確認してください。
· 派生クラスに名前を付けるときは、その親クラスの名前を使用する誘惑を避ける必要があります。クラスの名前はそれ自体にのみ関連し、親クラスの名前とは何の関係もありません。
· サフィックスが役立つ場合があります。たとえば、システムがエージェントを使用している場合、コンポーネントに「DownloadAgent」という名前を付けて、実際に情報を送信します。

2.3. メソッドと関数の名前付け

· 通常、各メソッドと関数はアクションを実行するため、その名前付けは、その動作を明確に示す必要があります: ErrorCheck() の代わりに CheckForErrors() を使用し、DataFile() の代わりに DumpDataToFile () を使用します。そうすることで、関数とデータがより区別しやすいオブジェクトになります。
· 接尾辞が役立つ場合があります:
o Max - エンティティに割り当てることができる最大値を意味します。
o Cnt - 実行中のカウント変数の現在値。
o キー - キーの値。
例: RetryMax は最大再試行数を表し、RetryCnt は現在の再試行数を表します。
· 接頭辞が役立つ場合があります:
o Is - 何かについて質問することを意味します。 Is を見るたびに、人々はそれが問題であることがわかります。
o Get - 値を取得することを意味します。
o Set - 値を設定することを意味します
例: IsHitRetryLimit。

2.4. 略語にはすべて大文字を使用しないでください

· いずれの場合でも、以下の状況に遭遇した場合は、略語を表すためにすべて大文字を使用する代わりに、最初の文字を大文字にし、残りの文字を小文字にすることができます。 。
使用: GetHtmlStatistic
使用しない: GetHTMLStatistic
理由
· 頭字語を含む名前を付けるときの直感は人によって大きく異なるようです。ネーミングの意味が完全に予測できるように、統一した規制を設けることが最善です。
NetworkABCKey の例を考えてみましょう。C が ABC の C であるべきか、キーの C であるべきかに注意してください。これは非常に混乱します。気にしない人もいれば、嫌う人もいます。したがって、コードごとに異なるルールが表示されるため、それを何と呼ぶべきかわかりません。
例
class FluidOz // FluidOZ は書かないでください
class GetHtmlStatistic // GetHTMLStatistic を書かないでください

2.5. クラスの名前付け

・単語の区切り文字には大文字を使用し、他の文字は小文字を使用します
・最初の文字は大文字を使用します名前
· アンダースコア ('_') を使用しないでください。
理由
· 多くの名前付け方法によれば、ほとんどの人がこれが最良の方法であると考えています。
例:
class NameOneTwo
class Name

2.6. クラス ライブラリの命名

· 現在、異なるベンダーやグループのクラス ライブラリ間のクラス名の競合を避けるために、名前空間がますます広く採用されています。
· 名前空間がまだ採用されていない場合、クラス名の競合を避けるために、クラス名の前に一意の接頭辞を追加するのが一般的です。もちろん、それ以上の文字を使用する方が良いでしょう。
たとえば、
John Johnson のデータ構造クラス ライブラリには、次のように Jj というプレフィックスを付けることができます:
class JjLinkList
{
}
もう 1 つの妥協案は、クラス ライブラリを含むディレクトリを作成することです (実際、Java もこれを行います)。ディレクトリは異なる名前空間を表します。
たとえば、
Microsoft のデータベース関連のクラス ライブラリは、次の場所にあります:
/classes/com/Microsoft/Database/DbConn.php
Apache のデータベース関連のクラス ライブラリは、次の場所にあります:
/classes/org/apache/Database/ DbConn.php

2.7. メソッドの名前付け

· クラスの名前付けと一致するルールを採用する
理由
· さまざまなルールをすべて使用するほとんどの人は、これが最良の妥協策であると考えています。
例:
class NameOneTwo
{
function DoIt() {};
function HandleError() {};
}

2.8. Generic** の名前付けには文字「m」を付ける必要があります。 。
· 接頭辞「m」の後には、クラス命名に関する一貫したルールが続きます。
· 「r」が参照を表すのと同じように、「m」は常に名前の先頭を修飾します。
理由
· 接頭辞「m」は、クラス** とメソッド名の競合を防止します。メソッド名とプロパティ名は、特に要素にアクセスする場合によく似ています。
例:
class NameOneTwo
function VarAbc() {};
var $mErrorNumber
}
2.9.
· 最初の文字には小文字を使用します。
· 最初の文字以降のすべての単語は、クラスの命名規則に従って大文字になります。
理由
・メソッド内の一般的な変数を区別できる。
· 名前の競合を引き起こすことなく、クラス名に似た名前を使用できます。
例:
class NameOneTwo
{
function StartYourEngines(
&$rSomeEngine,
&$rAnotherEngine);

2.10. 変数の名前付け

· すべての文字に小文字を使用します
· 区切り文字として「_」を使用します。各単語 。
理由
· このアプローチにより、コード内の変数の範囲が明確になります。
· すべての変数はコード内で異なって見えるため、簡単に識別できます。
例:
function HandleError($errorNumber)
$error = OsErr($errorNumber);
$error_processor = OsErr->GetErrorProcessor(); 2.11 . 参照を返す参照変数と関数

· 参照には接頭辞「r」を付ける必要があります
理由
· 異なる型の変数を簡単に識別できるようにします
· どのメソッドが可変オブジェクトを返し、どのメソッドが不変オブジェクトを返すかを決定できます。
例:
class Test
var mrStatus;
function DoSomething(&$rStatus) {};

2.12. グローバル変数には接頭辞「g」を付ける必要があります。 '。
理由
· 変数のスコープを知ることは非常に重要です。
例:
global $gLog;
global &$grLog;

2.13. 名前付き定数/グローバル定数を定義する

· グローバル定数は各単語を「_」で区切ります。
理由
これは、グローバル定数に名前を付ける伝統です。他の定義と矛盾しないように注意する必要があります。
例:
define("A_GLOBAL_CONSTANT", "Hello world!");

2.14. 静的変数

· 静的変数には接頭辞「s」を付ける必要があります。
理由
· 変数のスコープを知ることは非常に重要です。
例:
function test()
{
static $msStatus = 0;
}

2.15. 関数の名前付け

· 関数名はすべて小文字を使用し、「_」は別々の言葉。
理由
· これにより、関連するクラス名を区別しやすくなります。
例:
function some_bloody_function()
{
}

2.16. エラーリターン検出ルール

· エラーを無視したくない場合は、すべてのシステムコールでエラーメッセージを確認します。
· インクルードの各システム エラー メッセージのシステム エラー テキストを定義します。


3. 記述ルール


3.1. 中括弧 {} ルール

3 つの主要な中括弧配置ルールのうち、2 つが許容されますが、最初のルールが最適です:
· 中括弧はキーワードの下の同じ列に配置します。 :
if ($condition) while ($condition)
{ {
... ...
} }
· 従来の UNIX 括弧ルールでは、最初の括弧とキーワードが同じ列にあり、末尾が括弧はキーワードと同じ列にあります:
if ($condition) { while ($condition) {
... ...
} }
理由
· 激しい議論を引き起こした非原則的な問題は、次の方法で解決できます。妥協案の解決策としては、どちらの方法でも受け入れられますが、ほとんどの人にとっては最初の方法が好まれます。その理由は、心理学の研究と研究の分野にあるものです。
前者を好む理由は他にもあります。使用する文字エディターが括弧一致をサポートしている場合 (vi など)、最も重要なことは適切なスタイルを持つことです。なぜ？大規模なプログラムがあり、この大規模なプログラムがどこで終わるのかを知りたい場合に、このように言います。まず開始括弧に移動し、次にボタンを押すと、エディターは対応する終了括弧を見つけます。例:
if ($very_long_condition && $second_very_long_condition)
{
...
}
else if (...)
{
...
}
あるプログラム ブロックから別のプログラム ブロックに移動するには、カーソルを使用して括弧キーを一致させるだけです。一致する括弧を見つける必要はありません。

3.2. インデント/タブ/スペースのルール

· インデントにはタブを使用します。
· 各レベルのインデントには 3 ～ 4 つのスペースを使用します。
· 必要なときにインデントする必要はもうありません。インデント レベルの最大数に決まった規則はありません。インデント レベルの数が 4 または 5 を超える場合は、コードを除外することを検討できます。
理由
· 多くのプログラマがタブをサポートしています。
· あまりにも異なるタブ標準を使用すると、コードを読むのが難しくなります。
· 非常に多くの人がインデント レベルの最大数を制限しようとするため、それが仕事とはみなされないことがよくあります。私たちは、プログラマーがネストの深さを賢明に選択すると信じています。
例:
function func()
{
if (何か悪いこと)
{
if (別の悪いこと)
{
while (さらなる入力)
{
}
}
}
}

3.3.単語と関数のルール

· 括弧とキーワードを近づけず、スペースで区切ります。
· 括弧と関数名を近くに配置しないでください。
· 必要な場合を除き、Return ステートメントでは括弧を使用しないでください。
理由
· キーワードは関数ではありません。関数名とキーワードを括弧で囲んでいると、その 2 つが 1 つであることが簡単にわかります。
例:
if (条件)
{
}

while (条件)
{
}

return 1;

3.4.アーキテクチャ関数の動作

実際の作業はオブジェクト アーキテクチャ コンストラクターで実行しないでください。コンストラクターには、変数の初期化や失敗しない操作が含まれている必要があります。
理由
· コンストラクトはエラーを返すことができません。
例:
class Device
{
function Device() { /* 初期化など */ }
function Open() { return FAIL; }
};

$dev = new Device
if (FAIL ==) $ dev->Open()) exit(1);

3.5. If then Else のフォーマット

レイアウト
これはプログラマによって決定されます。ブレースのスタイルが異なると、外観も若干異なります。一般的な方法は次のとおりです:
if (条件 1) // コメント
{
}
else if (条件 2) // コメント
{
}
else // コメント
{
}
else if ステートメントを使用する場合、通常、処理されない他の状況を処理するには、else ブロックを使用することをお勧めします。可能であれば、else にアクションがない場合でも、else にレコード情報のコメントを入れてください。
条件付き書式設定
常に等号/不等号の左側に定数を置きます。例:
if ( 6 == $errorNum ) ...
理由の 1 つは、数式内で等号を見逃した場合、構文がチェッカー エラーが報告されます。 2 番目の理由は、式の最後で値を見つけるのではなく、すぐに値を見つけられることです。この形式に慣れるまで少し時間がかかりますが、非常にうまく機能します。

3.6. フォーマットの切り替え

· case ブロックが処理されると、処理のために次の case ブロックに直接進みます。この case ブロックの最後にコメントを追加する必要があります。
· デフォルトのケースは常に存在する必要があり、これに達することはできませんが、これに達するとエラーがトリガーされます。
· 変数を作成する場合は、すべてのコードをブロックに入れます。
例:
switch (...)
{
case 1:
...
// FALL THROUGH
case 2:
{
$v = get_week_number()
...
}
break;デフォルト :
}

3.7. continue、break および ? の使用

3.7.1. Continue と Break
Continue と Break は、実際には隠れた goto メソッドです。
Continue と Break は goto と似ており、コード内で魔法のように機能するため、使用は控えめに (できるだけ少なく) 行います。この単純な魔法を使用すると、読者は何らかの理由で神だけが知っている場所に導かれます。
Continue には 2 つの主な問題があります:
· テスト条件を回避する可能性があります。
· 等式/不等式式をバイパスできます。
次の例を見て、どこで問題が発生するかを検討してください。
while (TRUE)
{
...
// 大量のコード
...
if (/* 何らかの条件 */) {
continue ; }
...
// 大量のコード
...
if ( $i++ > STOP_VALUE) Break;
}
注: 「大量のコード」が必要ですが、これはプログラマが許可するためのものです。エラーを簡単に見つけられます。
上記の例を通じて、さらにルールを導き出すことができます。「継続」と「中断」を混ぜることは、災害を引き起こす正しい方法です。
3.7.2. ?:
問題は、多くの場合、? と : の間に多くのコードを詰め込もうとすることです。以下に、リンクに関する明確なルールをいくつか示します。
· 条件を括弧で囲んで、コードの残りの部分から分離します。
· 可能であれば、アクションには単純な関数を使用できます。
· アクション、「?」、「:」は、明確に同じ行に配置できない場合は、別の行に配置します。
例:
(condition) : func2();

or

(condition)
: 別の長いステートメント

· 宣言コード ブロックは次のとおりです。整列すること。
理由
・明確です。
· 変数初期化のための同様のコード ブロックがリストされるはずです。
· & は変数名ではなく、型の近くに配置する必要があります。
例:
var $mDate
var& $mrName
var $mName
$mDate = NULL;
$mName = NULL;あたりline ステートメント

ステートメントが密接に関連している場合を除き、1 行に 1 つのステートメントのみを記述します。

3.10. 短いメソッド

メソッドのコードは 1 ページに制限する必要があります。