- ご意見募集中: フォーラムで解決した FAQ や tips を Codex にまとめませんか?
- 注 WordPress 2.9 でサーバ要件 MySQL 4.1.2 以上に。/ドキュメントを更新して WordPress にご協力ください。
- 赤色のリンクは、まだ日本語Codex に存在しないページ・画像です。英語版と併せてご覧ください。(詳細)
- この Wiki はいつでも誰でも編集できます。ログインアカウントの取得からどうぞ :)
WordPress コーディング基準
出典: WordPress Codex 日本語版
WordPress のコード体系での PHP 記述は、いくつかのレガシーな部分において、形式に一貫性がありません。WordPress はこの状態を徐々に改善しようと作業していて、ユーザーの利便のため一貫した形式を維持するようにします。これにより、コードをきれいに、かつ一目で読みやすくなります。
WordPress のためにコードを書くときは、以下の点を心に留めておいてください。WordPress コアのプログラミングのみならず、プラグインの作成やWordPress テーマにおいてもです。このガイドラインは、Pear 標準に多くの点で似ていますが、いくつかの事項で異なります。
また、wp-hackers メーリングリストでの投稿もご覧ください。(訳注: 英語です)
インラインドキュメント基準/en を提案したページも見てください。
- シングルクォートとダブルクォート
- シングルクォートとダブルクォートは適切に使い分けてください。文字列で何も評価しない場合は、シングルクォートを使います。文字列で HTML クォートをエスケープする必要はほとんどありません。なぜなら、以下のようにクォート形式を変更すればいいからです:
echo '<a href="/static/link" title="Yeah yeah!">Link name</a>'; echo "<a href='$link' title='$linktitle'>$linkname</a>";
- (訳注: セキュリティ向上のためには、HTML 出力において、シングルクォートを使うのは好ましくありません。多少コードが読みにくくなっても、ダブルクォートを使うべきです)
- これに対する例外は JavaScript です。ダブルまたはシングルクォートのどちらかを強制されるときがあります。属性値となるテキストは attribute_escape() を通さなければなりませんが、こうするとシングルまたはダブルクォートが属性値の終了点を表わせず、XHTML 違反となり、セキュリティ問題が発生します。
- インデント
- インデントは論理的な構造を反映するようにしてください。本物のタブを使います。スペースはダメです。こうすると、多くの閲覧環境で柔軟に扱えます。
- 例外: 何かを整列させて読みやすくしたいコードブロックがあれば、最初のインデントはタブを使い、その後でスペースで差分を埋めることができます。
[tab]$foo = 'somevalue'; [tab]$foo2 = 'somevalue2'; [tab]$foo34 = 'somevalue3'; [tab]$foo5 = 'somevalue4';
- 最初のインデントにタブを使っていて、スペースは等号を一列に揃えるために使っていることに注意してください。
- ブレース (波かっこ) の形式
- ブレースは複数行のブロックを囲むのに使います。
if ( condition ) {
action1();
action2();
} elseif ( condition2 && condition3 ) {
action3();
action4();
} else {
defaultaction();
}
- その上で、非常に長いブロックがあれば、複数の短かいブロックまたは関数に分割できないか考慮してください。このような長いブロックが避けられないと考慮した場合、終了点に短かいコメントを置いてください。そうすると、一目見て終了ブレースが何の終わりであるか分かります。たいてい、約35行を越える論理ブロックに適用するのが適切です。そうでなくても、明らかには直感的でないコードならばコメントを付けて構いません。
単一行のブロックは、簡潔にするためブレースを省略できます:
if ( condition )
action1();
elseif ( condition2 )
action2();
else
action3();
- もし、関連するブロックのいずれかが2行以上の場合、すべての関連するブロックをブレースで囲んでください。
if ( condition ) {
action1();
} elseif ( condition2 ) {
action2a();
action2b();
}
- ループは、読みやすくするため、常にブレースで囲ってください。これにより、デバッグ時に数行編集したり、後に機能を追加するのが楽になります。
foreach ( $items as $item ) {
process_item( $item );
}
- include_once 対 require_once
- include_once と require_once との違いを学び、適切に使い分けてください。include() の PHP マニュアルを引用します:「これら2つの構文は、 エラーの扱い方を除けば全く同様に振舞います。エラーが発生するとどちらも Warning を出力しますが、 require() を使用している場合は Fatal Error となります」Fatal Error はスクリプトの実行を中止します。
- 正規表現
- Perl 互換の正規表現 (PCRE, preg_ 関数) を使うことが、POSIX 互換関数よりも好ましいです。
- PHP ショートタグは禁止
- 絶対に PHP のショートタグは使わないでください (<? ... ?> や <?=$var?>)。常に、完全な PHP タグ (<?php ... ?>) を使いましょう。PHP の閉じタグの後ろにホワイトスペースを除去することをお忘れなく。 (訳注: ホワイトスペースとは、空白、タブ、改行などのことです)
- スペースの使い方
- コンマの後ろや、論理演算子、代入演算子の両側には、常にスペースを入れてください。例えば、"x == 23", "foo && bar", "array( 1, 2, 3 )" のようにです。同様に、if, elseif, foreach, for and switch ブロックの開きかっこ、閉じかっこの両側にも入れてください (例: foreach ( $foo as $bar ) { ...)。関数を定義するときは、次のようにしてください: function myfunction( $param1 = 'foo', $param2 = 'bar' ) {
- SQL 文の書式
- SQL 文を書くときは、それを読みこなすのが複雑すぎる場合、複数の行に分割してインデントすることが可能です。多くの文は1行で書いた場合と同様に動きます。SQL の構文は常に大文字で書いてください。例えば、UPDATE や WHERE。
- データベースを更新する関数は、パラメータが渡されれたとき、SQL のスラッシュエスケープが欠けていると考えてください。できるだけクエリが実行される直近でエスケープを行なってください。このとき、$wpdb->prepare() を使うことが好ましいです。
- $wpdb->prepare() は、SQL クエリをエスケープしたり、クォートしたり、整数にキャストするメソッドです。sprintf() 書式のサブセットを使います。例:
$var = "dangerous'"; // raw data that may or may not need to be escaped $id = some_foo_number(); // data we expect to be an integer, but we're not certain $wpdb->query( $wpdb->prepare( "UPDATE $wpdb->posts SET post_title = %s WHERE ID = %d", $var, $id ) );
- %s は、文字列のプレースホルダー (入れ物) として、%d は整数のプレースホルダーとして使います。これらは 「クォート」しないことに注意してください。 $wpdb->prepare() が、エスケープやクォートを行なってくれます。こうすることで、わたしたちが、わざわざ $wpdb->escape() を使うことに気を付ける必要がなくなります。また、何がエスケープされ、されないのかを一目で見分けることができます。なぜなら、クエリを行うときに正しくエスケープが行なわれるからです。
詳しくはデータベースのデータ検証をご覧ください。
- データベースクエリ
- データベースを直接触ることは避けてください。必要とするデータを得る関数がすでに定義されている場合、それを使ってください。データベースの抽象化 (クエリの変わりに関数を使うこと) によって、コードの前方互換性を保つことができ、多くの場合、結果がメモリーにキャッシュされるため何倍も速く実行できます。もし、データベースを触る必要があるなら、wp-hackers メーリングリスト/en にメッセージを投稿して、開発者に連絡を取ってみてください。この人たちは、次の WordPress バージョンにおいて、あなたが望む機能を含む関数を作ることを検討するかもしれません (訳注: 英語で投稿する必要があります)。
- 変数、関数、ファイル名と演算子
- 変数名、関数名はアルファベット小文字を使い、単語の区切りはアンダースコア (_) を使ってください。単語の先頭を大文字にして繋げる形式 (キャメルケース; camelCase のような形式) は不可です。(訳注: 日本語文字列も使わないでください)
function some_name( $some_variable ) { [...] }
- ファイル名は動作を説明できるアルファベット小文字の名前にしてください。単語の区切りにはハイフン (-) を使います。(訳注: 日本語ファイル名も使わないでください)
my-plugin-name.php
- もし変数を1回しか使わないのなら、その変数を作ってはいけません。データベースクエリも同様です。データベースと交信するときは、必ず wpdb Class/en の関数を用いてください。
- 三項演算子は使っても構いません。ただし、文が true となるようなテストでなければなりません。false は不可です。そうでないと、混乱を招きます。
// よい例: // (if statement is true) ? (do this) : (if false, do this); $musictype = ( 'jazz' == $music ) ? 'cool' : 'blah';
- 上記の例において他に重要な点は、比較演算を行うとき、上記のように、変数は右側に置いてください。等号を1つ忘れたときパーサーはエラーを発生させます。true の結果を出したり、文を実行したりしません。これを行うには余計な時間は不要で、1つのバグを減らすという価値があります。
- 関数の引数のフラグは、意味の分かる値にしてください。関数を呼び出す場合は、単に true と false を用います。
//BAD
function eat( $what, $slowly = true ) {
...
}
eat( 'mushrooms' );
eat( 'mushrooms', true ); // what does true mean?
eat( 'dogfood', false ); // what does false mean? The opposite of true?
PHP は名前付き引数をサポートしません。フラグの値は意味を持たないので、上記のような方法で関数を呼び出すと、関数定義を探す必要があります。真偽ではなく、意味のある値にすると、コードの可読性が向上します。
//GOOD
function eat( $what, $speed = 'slowly' ) {
...
}
eat( 'mushrooms' );
eat( 'mushrooms', 'slowly' );
eat( 'dogfood', 'fast' );
最新英語版: WordPress Codex » WordPress Coding Standards (最新版との差分)

