仕様1

規格

PHP プログラム コーディング仕様標準
最終更新日: 2000-11-16
PHP プログラミング標準は、Todd Hoff の許可を得て、PHP 用に書き直されました。この標準を使用する場合は、次のとおりです。自分で使用するためにコピーを作成したい場合は、完全に無料です。それが私たちが作成した理由です。バグを見つけた場合や改善点がある場合は、最新の更新に組み込むことができるように電子メールを送ってください。
目次
はじめに
標準化の重要性
説明
アイデンティティ
プロジェクトの4つのフェーズ
命名ルール
適切な命名
略語にすべて大文字を使用しない
クラスの命名
クラスライブラリの命名
メソッドの命名
クラス属性名前付け
メソッド内のパラメータの名前付け
変数の名前付け
参照変数と関数の戻り参照
グローバル変数
定義の名前付け/グローバル定数
静的変数
関数の名前付け
php ファイル拡張子
文書ルール
評価コメント
コメントはストーリーを伝えるべき
文書決定
ヘッダー命令を使用する
注意点を明示する
インターフェイスと実装のドキュメント
ディレクトリのドキュメント
複雑さの管理ルール
階層化
オープン/クローズの原則
契約による設計
クラスルール
異なるアクセサースタイル
オブジェクトアーキテクチャ中に実際の作業を行わない期間
Thin クラス インターフェイスと Fat クラス インターフェイス
短いメソッド
プロセス ルール
設計表記法とプロセスを使用する
ユースケースを使用する
コード レビュー
ソース コード管理システムを頻繁に作成せずに早期に作成する
バグ追跡システムを頻繁に作成せずに早期に作成する
RCS キーワード、変更ログ、および履歴のルール
責任の尊重
書式設定
中括弧 {} のルール
インデント/タブ/スペースのルール
親、キーワードおよび関数のルール
If then Else 形式
switch 形式
continue 、break と ? の使用
1 つのステートメント1 行ごと
宣言ブロックの位置
一般的な通説
OO の約束
その他
信じられないほどの数値を使用しない
エラー戻り検出ルール
ゼロ以外の値をテストするためにデフォルト値を使用しない
ブール論理型
通常、埋め込み割り当ては避けてください
自分や他の人が苦労して作成したものを再利用します
if (0) を使用して外側のコード ブロックをコメントアウトします
その他
----------------------- ---------------------------------------------------- --------- ----------
はじめに
標準化の重要性
標準化の問題は、ある面では誰もが頭痛の種となり、誰もが同じ状況にあると感じさせます。これにより、多くのプロジェクトで推奨事項が進化し、多くの企業が何週間もかけて一字一句議論することになりました。標準化は特別な個人的なスタイルではなく、ローカルな改善に完全に開かれています。
利点
プロジェクトが公的標準に準拠しようとすると、次のような利点があります:
プログラマーはあらゆるコードを理解し、プログラムのステータスを理解できます
新しい人はすぐに環境に適応できます
PHP を初めて使用する人が保存できないようにします必要な時間を確保し、一連のスタイルを作成し、生涯にわたる習慣を身につけましょう
PHP を初めて使用する人が同じ間違いを何度も繰り返さないようにします
一貫した環境では、間違いを犯す可能性を減らすことができます
プログラマーには一貫した敵がいます :-)
短所
次は短所です:
標準は php を知らない人によって作られているため、通常、標準は愚かに見えます
標準は私がやっていることと異なるため、通常、標準は愚かに見えます
標準は創造性を低下させます
標準は長時間お互いに共同作業する人々には不必要です
標準によって強制されるフォーマットが多すぎます
要するに、人々は標準を無視しています
ディスカッション
多くのプロジェクトの経験から、次の結論に至る可能性があります:プログラミング標準を採用することで、プロジェクトをよりスムーズに完了させることができます。成功の鍵は標準ですか?もちろん違います。しかし、彼らは私たちを助けてくれるはずです。私たちはできる限りの助けを必要としています。正直に言うと、
詳細規格に対する議論のほとんどは主に利己主義から生じています。妥当な基準をほとんど決定しないと専門性が欠けていると言えるのは、単に好みの問題です。したがって、柔軟性を持ってエゴを抑制し、どんなプロジェクトもチームの努力に依存していることを忘れないでください。
説明
規約
この文書での「必須」という言葉の使用は、この仕様を使用するすべてのプロジェクトが指定された標準に準拠する必要があることを意味します。
「すべき」という言葉を使用する目的は、プロジェクトをガイドしてプロジェクトの詳細をカスタマイズすることです。プロジェクトには要件を適切に含めたり、除外したり、調整したりする必要があるためです。
「できる」という単語の使用は、オプションの要件を指定するという点で「すべき」と同様に機能します。
標準実装
最初に、開発チーム内の最も重要な要素をすべて特定する必要があります。もしかしたら、その標準があなたの状況に十分に適切ではないかもしれません。重要な論点がまとめられていたかもしれないし、あるいはその一部に対して強い反対意見があったかもしれない。
どんな状況であっても、最終的にうまくいっていれば、この標準が合理的であることを理解できるほど人々は成長し、その後他のプログラマーも成長します
また、それが合理的であることがわかり、多少の留保はつきながらもこの基準に従う価値があると感じるでしょう。
自発的な協力がない場合は、要件を策定することができます。標準はコードによってテストする必要があります。
検討しなければ、このソリューションは不正確な基盤の上に構築されたばかばかしいものの束にすぎません。
その意見には同意します
これはうまくいきません
それはうまくいくかもしれませんが、それは非現実的で退屈です
これは私が最初に考えたことです
それはです;そうあるべきだ。
もしあなたがネガティブな偏見を持って物事を見るようになった場合は、広い心でいてください。それでも「くだらない」と結論付けることはできますが、そのためには、さまざまなアイデアを受け入れる必要があります。時間に余裕を持って取り組んでください。
プロジェクトの 4 つのフェーズ
データベース構造
設計
データ層
HTML 層
-------------------------------- ----------------------------------------
ネーミングルール
適切なネーミング
ネーミングとは番組企画の核心。古代人は、人の本当の名前を知っている限り、その人に対して信じられないほどの力を得ることができると信じていました。物事に適切な名前を考えている限り、それはあなたとあなたの後に続く人たちに、コードよりも大きな力を与えるでしょう。笑うな！
その名前は、それが位置する生態環境における何かの長期的かつ広範囲にわたる結果です。一般に、システムを理解しているプログラマだけが、システムに最も適切な名前を選択できます。すべての名前が自然に適切であれば、関係は明らかであり、意味を推測することができ、一般の人々の推論が期待されます。
対応するオブジェクトに一致する名前が少数しかない場合は、デザインをもう一度よく見ることをお勧めします。
クラスの名前付け
クラスに名前を付ける前に、まずそれが何であるかを知る必要があります。クラス名から得られる手がかりに基づいても、このクラスが何であるかを思い出せない場合は、設計が十分ではありません。
3 つ以上の単語で構成される名前が混在していると、システム内のさまざまなエンティティ間で混乱が生じやすくなります。設計を確認し、(CRC Se-
ssion カード) を使用して、名前に対応するエンティティに多くの単語が含まれているかどうかを確認してください。機能。 。
派生クラスに名前を付けるときは、その親クラスの名前を使用する誘惑を避ける必要があります。クラスの名前はそれ自体にのみ関連し、その親クラスの名前とは何の関係もありません。
サフィックスが役立つ場合があります。たとえば、システムがエージェントを使用している場合、実際に情報を送信するコンポーネントに「DownloadAgent」という名前を付けます。
メソッドと関数の名前付け
通常、各メソッドと関数はアクションを実行するため、その名前付けはその動作を明確に示す必要があります。ErrorCheck() の代わりに
CheckForErrors() を使用し、DataFile () の代わりに DumpDataToFile() を使用します。そうすることで、関数とデータがより区別しやすいオブジェクトになります。
サフィックスが役立つ場合があります:
Max - エンティティに割り当てることができる最大値を意味します。
Cnt - 実行中のカウント変数の現在値。
キー - キーの値。
例: RetryMax は最大再試行数を表し、RetryCnt は現在の再試行数を表します。
場合によっては接頭辞が便利です:
Is - 何かについて質問することを意味します。 Is を見るたびに、人々はそれが問題であることがわかります。
Get - 値を取得することを意味します。
Set - 値を設定することを意味します
例: IsHitRetryLimit。
略語にはすべて大文字を使用しないでください
いずれの場合でも、次の状況に遭遇した場合は、略語を表すためにすべて大文字を使用する代わりに、最初の文字を大文字にし、残りの文字を小文字にすることができます。
使用: GetHtmlStatistic
使用しない: GetHTMLStatistic.
理由
名前に略語が含まれる場合、人々の直感は大きく異なるようです。ネーミングの意味が完全に予測できるように、統一した規定を設けるのが最善です。
NetworkABCKey の例を考えてみましょう。C が ABC の C であるべきか、キーの C であるべきかに注意してください。これは非常に混乱します。これを気にしない人もいれば、それを嫌う人もいます。したがって、コードごとに異なるルールが表示されるため、それを呼び出す方法がわかりません。
例:
class FluidOz //FluidOZ は記述しないでください
class GetHtmlStatistic //GetHTMLStatistic を記述しないでください
---------------------------- ----------------- --------------------------------- -----------------
クラスの名前付け
単語の区切り文字として大文字を使用し、その他の文字は小文字を使用
名前の最初の文字には大文字を使用
アンダースコア (' _')
理由
多くの命名方法によると、ほとんどの人がこれが最良の方法であると考えています。
例:
クラス名 OneTwo
クラス名
----------------------------------------------------- - --------------------------------------
クラスライブラリの命名
現在、名前空間はますます広く採用されるようになり、異なるベンダーやグループ ライブラリ間でのクラス名の競合を回避できる可能性が高くなります。
名前空間がまだ使用されていない場合は、クラス名の競合を避けるために、クラス名の前に一意の接頭辞を追加するのが一般的です。もちろん、それ以上の文字を使用することをお勧めします。
たとえば、
John Johnson のデータ構造クラス ライブラリには、次のように Jj というプレフィックスを付けることができます:
class JjLinkList
{
}
---------------------- --- --------------------------------------------------- --- -------
メソッドの名前付け
クラスの名前付けに一貫したルールを採用する
理由
さまざまなルールをすべて使用するほとんどの人は、これが最善の妥協点であると考えています。
例:
class NameOneTwo
{
function DoIt() {};
function HandleError() {};
}
---------------------- -------------------------------------------------- - ------
クラス属性の名前付け
属性名の先頭には文字「m」を付ける必要があります。
接頭辞「m」は、クラス命名に関する一貫した規則に従います。
「r」で始まるのが参照を表すのと同じように、「m」は常に名前の先頭を変更します。
理由
接頭辞「m」は、クラス属性とメソッド名の間の競合を防ぎます。メソッド名とプロパティ名は、特に要素にアクセスする場合によく似ています。
例例例：classnameonetwo
class nameonetwo
-------------- -------------------------------------------------------------------------------------------------------------------------- -------------------------- ------------------------
の最初の文字メソッドパラメータの命名
には小文字が使用されます。
最初の文字以降の単語はすべて、クラスの命名規則に従って大文字になります。
理由
どの変数がどの変数に対応するかをいつでも知ることができます。
名前の競合を引き起こすことなく、クラス名に似た名前を使用できます。 A たとえば、
Class Nameonetwo
{
Function Startyourengines (
& $ RSOMEE​​NGINE,
& $ Ranotherngine)
}
----------- - ------------------------------------------------- - ----
変数の名前付け
すべて小文字を使用します
各単語の区切り文字として「_」を使用します。
理由
このアプローチにより、コード内の変数の範囲が明確になります。
すべての変数はコード内で異なって見えるため、簡単に識別できます。 N たとえば、
Function Handlererror ($ errornumber) {
$ error = osr ();
$ Time_of_error = & GT; --------------------------------- ------------------- ----
参照変数と関数の戻り参照
参照には「r」というプレフィックスを付ける必要があります
理由
異なる型の変数を識別しやすくするため
どのメソッドが変更可能なオブジェクトを返し、どのメソッドが変更不可能なオブジェクトを返すかを決定できます。
例:
class Test
{
var mrStatus;
function DoSomething(&$rStatus) {};
function &rStatus() {};
}
---------------- -------------------------------------------------- - -------------
グローバル変数
グローバル変数には接頭辞「g」を付ける必要があります。
理由
変数のスコープを知ることは非常に重要です。
例:
global $gLog;
global &$grLog;
------------------------------------- ------------------------ -------------------------------------------- -------------
名前付き定数/グローバル定数を定義する
グローバル定数は、各単語を「_」で区切ります。
理由
これは、グローバル定数に名前を付ける伝統です。他の定義と矛盾しないように注意する必要があります。
例:
define("A_GLOBAL_CONSTANT", "Hello world!");
-------------------------------- -------------------------------------------------- -
静的変数
静的変数には接頭辞「s」を付ける必要があります。
理由
変数のスコープを知ることは非常に重要です。
例: function test(){ static $msStatus = 0;
}
-------------------------------- -------------------------------------------------- -
関数の名前付け
関数名は C GNU の規則に従い、すべての文字は小文字で、単語の区切りには '_' が使用されます。
理由
これにより、関連するクラス名を区別しやすくなります。
例: function some_bloody_function()
{
}
-------------------------------------------------- ----------------------------------
エラーリターン検出ルール
すべてのシステムコールでエラーメッセージをチェックしてください。エラーを無視したい。
インクルードの各システム エラー メッセージのシステム エラー テキストを定義します。
------------------------------------------------- ----------------------------------
中括弧 {} ルール
3 つの主要な中括弧配置ルールには、次のものがあります。最初の 2 つが最適です:
キーワードの下の同じ列に括弧を配置します:
if ($ Condition) While ($ Condition) {{
... ... ..
} 的従来の UNIX の括弧ルールは、最初の括弧とキーワードです。
理由
激しい議論を引き起こした非原則的な問題は、どちらの方法でも解決できますが、ほとんどの人は最初の方法を好みます。その理由は、心理学の研究と研究の分野にあるものです。
前者を好む理由は他にもあります。使用する文字エディターが括弧一致をサポートしている場合 (vi など)、最も重要なことは適切なスタイルを持つことです。なぜ？大規模なプログラムがあり、この大規模なプログラムがどこで終わるのかを知りたい場合に、このように言います。最初に開始括弧に移動してからボタンを押すと、エディターは対応する終了括弧を見つけます。例:
if ($very_long_condition && $second_very_long_condition)
{
...
}
else if (...) ️あるプログラム ブロックから別のプログラム ブロックに移動するには、次のようにします。カーソルと括弧一致キーを使用すると、一致する括弧を見つけるために行末まで前後に移動する必要はありません
。
------------------------------------------------- ----------------------------------
インデント/タブ/スペースのルール
インデントにはタブを使用します。
各レベルのインデントには 3 ～ 4 つのスペースを使用します。
必要なときにインデントする必要はもうありません。インデント レベルの最大数についての固定ルールはありません。インデント レベルの数が 4、
、または 5 を超える場合は、コードを除外することを検討できます。
理由
多くのプログラマーがタブをサポートしています。
タブは暴走族のために発明されたものです
あまりにも異なるタブ標準を使用すると、コードを読むのが非常に面倒になります。
非常に多くの人がインデント レベルの最大数を制限しようとしますが、多くの場合、それは仕事とは見なされません。私たちは、プログラマーがネストの深さ
を賢明に選択すると信じています。
例:
function func() {
}
> ------------ -----------------------
括弧、キーワード、関数のルール
括弧やキーワードは入れないでください互いに近づけたり、スペースで区切ったりします。
括弧と関数名を近くに配置しないでください。
必要な場合を除き、Return ステートメントでは括弧を使用しないでください。
Reason
キーワードは関数ではありません。関数名とキーワードを括弧で囲んでいると、その 2 つが 1 つであることが簡単にわかります。
例
if (条件)
{
}
while (条件)
{
}
strcmp($s, $s1);
1 を返す;
---------------------------------------------- --- ----------------------------------
RCS キーワード、変更記録と履歴ルール
RCS キーを使用するRCS スタイルのキーワードをサポートする CVS や同様のソース コード管理システムの使用を含め、キーワード ルールを直接変更する必要があります:
ファイル内で RCS キーワードを使用しないでください。
変更履歴の記録をファイルに保存しないでください。
著者情報レコードをファイルに保存しないでください。
理由
その理由は、ソース管理システムがすでにこれらの情報をすべて保持しているためです。次のような重複情報でソース ファイルを乱雑にする理由はありません。
ファイルが大きくなる
ソース コード以外の行が変更されるため、差分が困難になる
エントリが作成されるファイルの数十行下にあるファイルに埋め込むため、ファイルごとに検索やジャンプが必要になります
ソースコード管理システムから簡単に入手でき、ファイルに埋め込む必要がありません
ファイルを他の組織に送信する必要がある場合、コメントが含まれる場合があります部外者に公開すべきではない内部詳細が含まれています
-------------------------------------- --- ------------------------------------------
やってはいけないことオブジェクト アーキテクチャ期間中の実際的な作業 オブジェクトの構築中に実際の作業を実行したり、変数を初期化したり、構築中にエラーのない作業を行ったりしないでください。
オブジェクト構造が完了したら、オブジェクトの Open() メソッドを作成します。 Open() メソッドには、オブジェクト エンティティにちなんで名前を付ける必要があります。
理由
Construction はエラーを返すことができません。
例:
class Device
{
function Device() { /* 初期化とその他 */ }
function Open() { return FAIL; }
};
$dev = new Device;
if (FAIL == $ dev ->Open()) exit(1);
-------------------------------------------- ---------------------------------------------------- --