スラッシュドット・ジャパン

趣味でやっている人のことは、まあ、いいとして（踏み台にされる可能性はあるけど）、仕事でPHPを使うときの注意を書いておこう。

• コーディング規約を守る。組織にコーディング規約がないなら、Zend Framework PHP標準コーディング規約 [zend.com]を使う。オレ流コーディングスタイルは禁止。
• 内部コードにはEUC-JPかUTF-8を使う。入出力もできるだけShift JISを避ける。Shift JISを使う場合には2byte目に0x5Cを含む文字の動作を忘れずに確認する。
• 開発環境の警告レベルをE_STRICTにする。本番環境ではdisplay_errorsをオフにする。
• register_globals、magic_quotesはオフにする。
• type hintingを積極的に使う。
• スコープの長い配列をクラスでラップする。
• プレゼンテーションとロジックを分割すること。プレゼンテーションには変数または関数の出力とループ以外のロジックを残さないこと。ロジックの中で直接出力をしないこと。ロジックはSimpleTestを使って単体テストすること。
• SQL文に変数を埋め込むときにはプレースホルダを使う（PDOのprepareとbindParams）。
• リクエストから取得したパラメータを出力するときはhtmlspecialcharsを使う。
• 関数が長くなったら分割する（composite methodパターンを使おう）。
• グローバル変数を使うのは避ける。
• 変数を定数として使わない。定数はdefineで定義するか、const宣言する。
• 常に最新バージョンでテストできる環境を作り、サービスイン後もバージョンアップに対応するための予算をとっておく（サービスイン後にお金をかけたくないなら、PHPは避けるべき）。
• 継承を使うなら、クラス図くらいは書いておく（単にコードを再利用したいだけなら、移譲を検討すること）。
• 各URLにおけるパラメータとその閾値を文書化すること。パラメータの閾値の境界線についてソースレビューし、テストすること。
• 既存のフレームワークを学習することに投資すること（学習コストを嫌って自己流のフレームワークを作ることは、バグを作りこむことになるのでかえってコスト高になる）。
• PHPしか使えない作業者の成果物はこまめにレビューすること。
• 設計を重視すること。
• コピー＆ペーストプログラミングの匂いを発見したら、そのコードを書いた人にプログラミングの基礎を教えること。
• リファクタリングの時間をスケジュールに入れること。
• require/includeを条件文や関数宣言の中に記述しないこと。

PHPに限らない話も多いけどね。PHPを採用するときって「期間」「人材」が理由になることが多いけれど、それらの問題を解決できるほどPHPは素晴らしいものではない、ということは知っておいてもいいんじゃないかと。百戦錬磨の腕利きたちがいるとき、期間を短くするためにPHPを使うのはいいでしょう。人材不足でPHPができる人しか揃わないときは、PHPしかないですよね。でもね、両方の場合はプロジェクトを断念する方が間違いないです。未熟なプログラマーでも素早くWebアプリケーションを十分な品質で作れる方法なんかないですから。

# まあ、それはそれとしても、PHPの言語仕様がいろいろトホホなのは確かだけど。

株式会社 社会式株 PHPコーディング規約 [sksk.info]

> ・スコープの長い配列をクラスでラップする。

関数とのデータの受け渡しに連想配列なんかを使われると地獄。
関数に引き渡すデータを構築するために、実際にその配列が使われている箇所のコードを
精読しないといけなかったり、逆に関数から返される配列の中身を調べるのに苦労したり。
その上、実際にその連想配列を使ったり組み立てたりしているのは、深い深いところにあ
るルーチンだったりして、結局その動作解析に時間を使ってしまったりして。

ドキュメント書けよ...っていうのと同根なんだけど、ドキュメントがあっても複雑さは
消えないんですよね。
クラスだったら、その定義を見ればデータ構造は一目瞭然（の場合が多い）って主張はし
ているんですが、楽なんですよね連想配列は。
いきなり（定義なしに）複雑なデータ構造を組み立てられるから。

# 個人的には、ファイルをまたぐ場合には連想配列は使わないようにしています。

> # リクエストから取得したパラメータを出力するときはhtmlspecialcharsを使う。
×。
これは、「リクエストから取得した」と限定をつけて覚えてはいけない。（少数の例外を除き）いかなる場所から取得したデータ（変数）でも、が正しい。たとえ明らかにエスケープが要らない場合でも、コーディング規約とするなら、「必ずエスケープする」、とするべき。必要な場所で忘れないために。

あと、クエリ文字列の場合は urlencode であることも忘れないように。

> > 関数が長くなったら分割する（composite methodパターンを使おう）。

> PHPは知らないのですが、
> 単なる関数分割をCompositePatternと呼ぶのですか？

ケント・ベックの Smalltalk ベストプラクティス・パターン [amazon.co.jp]でそのように紹介されています。
パターンと名前についているが GoF 本のようなデザインパターンではなく、
良いプログラミングスタイルについて書かれたもの。

... だと思います。自分も PHP は知らない。

ruby での例 [biglobe.ne.jp]