PEARなどの有名どころのライブラリーやアプリケーションには
「コーディング規約」としてプログラミングの際の約束ごとがあります。
覚えることが多い頃には正直めんどくさくて見てません、
というより見る余裕がありませんでした。
そんなころに書いたコードにちょっと変更を加えたらエラー連発！
エラーが出るのはマシな方で、エラーも出てないのに
意図した通り動かない！って経験を何度か繰り返してるうちに
「コーディング規約」は必要だよなと思えるようになりました。
まあ、意図した通りに動かなかったのはこんなのでした。
// 本来↓こう書くべきところを
if ($car == 'skyline')
// ↓こうしてしまった単純なタイプミス。
if ($car = 'skyline')
これでも構文エラーにならなのでミスに気づけない、はまってしまうワナ。
もし↓こう書いていれば構文エラーですぐに原因を発見できたのですよ。
if ('skyline' = $car)
大きな時間の浪費につながる単純ミスをおかさないため
絶対やるようになった「オレおれコーディング指針」がこれ。
変数は比較演算子の右＆厳密に型も比較する
if ('skyline' === $car)
先に挙げたはまった事例。比較演算子のタイプミスを発見しやすくする働きがある。
さらに厳密な比較にすると、暗黙の型キャストが行われないので、比較処理が早くなる。
先ず両辺の型が比較され一致してる時だけ値が比較されるという処理流れらしい。
実行文が1つでも if文の {} は省略しない
// 実行文が1つなので {} を省略していたが
if ('windows' === $os)
echo 'I like to.';
// 実行文を2つに増やしたつもり...
// でも {} を付け忘れてるので2番目の文が常に実行される状態
if ('windows' === $os)
echo 'I like to.';
echo 'Do you like Mac?';
この程度ならすぐわかると思いきやこれも構文エラーにならないので
ステップ実行か、コードを追って見つけるしか手が無いす。
if文が何重にも入れ子になってるともう見つからんです。
変数の展開がない文字列はシングルクォーテーション（’）で囲む
$str = '<a href="/skyline">Skyline</a>';
文字列をダブルクォーテーションで囲むとエスケープ（\）が必要な文字が増える。
ましてHTML混じりだったりするとどこまでが文字列なのかわかりづらくなるけど
シングルクォーテーションで囲んでいればエスケープは最小限（\と’）で済むし
変数の展開をしないただの文字列にダブルクォーテーションは必要ないし。
// 変数の展開を期待してる時のみダブルクォーテーションを使う $str = "<a href=\"$url\">Skyline</a>"; // でもエスケープが無い方が読みやすいので連結しますけど $str = '<a href="'. $url. '">Skyline</a>';
コメントは（無理にでも）英数字で書く
マルチバイト文字が混ざるファイルはひとつでも減らしておく方が
サーバー移転など環境の変化に対応しやすい。
データとしてマルチバイト文字が入るファイルには注意が向くけど
コメントのマルチバイト文字の事は、引越しするくらい時間が経ってると
すっかり頭の中から消えてます。まちがいなく。
英語が出来なけりゃ、ローマ字コメントという奥の手もある。
「制御構造に関する別の構文」を使うのはテンプレートファイルだけ
テンプレートファイルで使うとブロックの範囲がわかりやすくなるけど
それ以外に使うと逆にわかりづらい。
絶対やってるのはこんなとこ。
ファイルの管理方法とか命名規則とかコメントのつけ方とかインデントとかは
時々に応じ決めてさえいればいいかなって感じです。
ちなみにインデントはTAB譜、いやTab派です。
参考
