1. チーム開発を
うまく行うための
コーディング規約論
[PHP編]
株式会社インフィニットループ
ke-tai.org
松井健太郎

2. 自己紹介
• 株式会社インフィニットループ代表
• ケータイプログラマのための
情報サイト「ke-tai.org」管理人
• コーラが好き

3. 本日の内容
• コーディング規約とは
• コーディング規約はなぜ必要か
• 目的と考え方
• 具体的なコーディング規約
• コーディング規約で悩んでいること
※ご注意
この資料内で具体例として取上げているコーディング規約は、
あくまで弊社で勝手に定めているものです。
案件内容や構成スタッフによって最適解は異なります。

4. コーディング規約とは
Wikipedaより
• プログラミング作法（Programming style）、コー
ディング標準（Coding Standards）とも呼ばれる
• プログラムのソースコードを書くときの規則やガ
イドライン群を指す。特定のプログラミング作法
に従っていれば、コードを読んで理解するのが容
易になり、間違う可能性も減らせるとする思想。

5. コーディング規約はなぜ必要か(1)
外注など不特定多数の人が参加するにつれ、
いろんなコードを書く人が増えてくる
→ なんでもグローバル変数に格納する人
→ GOTOを使う人
→ 関数を使わずにincludeで処理を書く人
【マネージャーにとっての利点】
• 品質の安定化に繋がる
• 他のスタッフに引き継ぎがしやすい

6. コーディング規約はなぜ必要か(2)
【プログラマにとっての利点】
• 他人が書いた部分のコードが読みやすい
• 「気持ち悪い」を減らせる
• grepしやすい
• ハマりどころを回避できる
→ PHPがダメ言語だと言うのなら、規約で可能な限り回避したらいいじゃない

7. 目的と考え方
• 個人の限界を越えるため
→ 規模の大きい案件では、チーム開発が必須 （例：ソーシャルゲームなど）
→ 個人よがりの考えは無視し、最大公約数的なポイントを模索する
• スキルの低い人の救済を目指す
→ ハマりどころを意識しなくて済むように
→ 迷った時はスキルの低い人向けに合わせる
• 開発効率をあげる
→ 可読性やgrepしやすさを意識する
→ 2通り以上の書き方が出来るものは、1種類に統一する
→ 開発効率を落とさぬ範囲内で、ちょっと厳しすぎるかな、くらいを目指す
• 不毛な宗教戦争は起こさない
→ 機能性（バグの起きにくさなど） ＞ シンプルさ・わかりやすさ ＞ 気持ち悪さ
→ 我々は仕事でコードを書いている、仕事である以上コーディング規約を守ろう
→ 自分のスタイルで書きたい人はご自宅で

8. 具体的なコーディング規約(1)
原則
• PEAR標準コーディング規約をベースにしている
http://pear.php.net/manual/ja/standards.php
• PHPの偉い人たちが考えたものなので、さすがよくで
きている
• マニュアルなどで目にしているせいか、意外と違和感
がなくなじみやすい
• これをベースに使いづらい箇所を直し、細かい要素を
追加していく

9. 具体的なコーディング規約(2)
文字コード、基本ルール
• 文字コードは「UTF-8(BOMなし)」で記述する
• 改行コードには「LF改行」を使う
• 「<?」(short_open_tags)ではなく「<?php」を利用する
→ XMLとの共存を行いやすくするため
• 「?>」（閉じPHPタグ）は省略し記述しない
→ 不要な改行が出力されるトラブルを防ぐため
• タブ幅は4とする
→ スペースを使ったインデントや8タブなどは使わない 宗教戦争ポイント！
宗教戦争ポイント！
ポイント

10. 具体的なコーディング規約(3)
改行ルール
• ソースコードが横に長い場合でも改行はしない
宗教戦争ポイント！
宗教戦争ポイント！
ポイント
基本： 改行なし
例外1： 条件文を書くときは改行可
if ($hogehoge == $pugepuge and $hogehoge == $pugapuga or
$hogehoge == $pegopego and $hogehoge == $chomechome) {
理由：
・画面幅は人それぞれ
・何文字で改行するかの意見が皆バラバラで結
論がでなかった
例外2： 配列への代入の時は改行可 ・イヤならエディタ側で改行すればいいじゃない
$hoge = array(
'abc' => 'def',
'ghi' => 'jkl',
'mno' => 'pqr‘
);
※関数呼び出しの際にも改行したいとの声があったが、
それは関数の設計が間違っているのでは？ということになった

11. 具体的なコーディング規約(4)
スペースのあけ方
• 代入や演算、文字列の連結
× $a=$b*2; × $a='a'.'b';
○ $a = $b * 2; ○ $a= 'a' . 'b';
• 配列、関数の引数
× array(1,2,3) × sampleFunction('foo','bar')
○ array(1, 2, 3) ○ sampleFunction('foo', 'bar')
• 制御構造
× switch($foo) {
○ switch ($foo) {
• コメント
× //コメント文字列
○ // コメント文字列

12. 具体的なコーディング規約(5)
分岐・条件式
• ifはリテラルを前にして記述する（=を一つしか付けず代入となって
気付きづらいというミスを起こさないため） 宗教戦争ポイント！
宗教戦争ポイント！
ポイント
× if ($a == 'hoge') {
○ if ('hoge' == $a) {
• 「and, or」を使い、「&&, ||」は使わないこと
宗教戦争ポイント！
宗教戦争ポイント！
ポイント
• 三項演算子は使わない 別にどちらでもいいけど、
$res = (0 == $value ? true : false); どちらかに統一したかった
• 「{」「}」（波カッコ）の省略はしないこと
if (0 == $value) return true;

13. 具体的なコーディング規約(6)
コメント
• コメントについての考え方
→ コメントは、他人のため、もしくは2年後の自分のために書くこと
→ このコードを引き継ぐのは、自分より数段スキルが低い技術者であると思うこと
→ 何をしているかはコードを見ればわかるので、なぜそうしているのかを書くこと
→ 口語体やくだけた言葉でコメントを書くのは絶対に止める。プロ意識を持つこと
→ 他人がレビューする際にまず見るのはコメント
コメントがいい加減なコードは絶対に信頼を得られないということをよく知ること
• コメントは「//」または「/* ～ */」を使い、「#」は使わないこと

14. 具体的なコーディング規約(7)
コメント
• 多数の行に渡りコメントアウトする際には原則「//」を使うこと。
「/* */」を使うときはgrepでわかるようにするためJavaDoc形式
のように頭に*をつけること
誤った例：
以下のような形だとgrepした際にコメントアウトされていることがわからない
/*
$res1 = sampleFunction(1);
$res2 = sampleFunction(2);
*/
正しい例：
// $res1 = sampleFunction(1);
// $res2 = sampleFunction(2);

15. 具体的なコーディング規約(8)
コメント
• 処理ブロックに対しコメントを付ける場合の例
// DB登録処理
$sql_str = "SELECT * from data_tbl";
$result = $db->query($sql_str);
• 1行の処理に対しコメントを付ける場合の例
$db->commit(); // DBのコミット
分岐にしっかりコメントをつけ
れるだけでも、可読性はずい
ぶんと違う
• 分岐に対してコメントを付ける場合の例
// ページ数が最大を超えているかを調べる（※この分岐ブロックに対するコメント）
if (MAX_PAGE <= $p) {
// 最大ページ数を超えている場合（※どういう条件でここに入るかのコメント）
echo “ここが最後のページです”;
} else {
// 最大ページ数を超えていない場合（※elseの場合でもなるべく省略しない方がよい）
// 次ページのデータを生成する（※処理ブロックコメントを書きたい場合は1行あけて書く）
$page_str = sprintf('次ページがあります (%d / %d)', $p, MAX_PAGE);
echo $page_str;
}

16. 具体的なコーディング規約(9)
関数
複数の書き方ができるものは、なるべくまとめていく
• キャスト演算子をやめる
→ (int)の代わりに、intvalを使うなど
• empty()は使わず、isset()を使う
→ empty()とisset()は挙動が違う、これを毎回説明するくらいなら使用禁止にする
• 正規表現はpreg系を使う
などなど

17. 具体的なコーディング規約(10)
その他
• 無名関数はなるべく使わない
→ 初心者には理解できない恐れ
→ 無名関数でなくてはならないケースがそれほど無い
• 日付計算の”-1 month”などはやめる
→ できればDatetimeなどを使うのがいい
• gotoやglobalは使わない
• 時間系の定義は、書く順番を決める
define('HOGE_HOGE_INTERBAL', 60 * 60 * 24 * 3);
※その他いろいろありますが、書ききれないので省略

18. コーディング規約
今後
• 使わない関数をもう少し吟味していく
• SQLの書き方にも規約を設ける
→ SQLは可読性が重要な箇所
• 正規表現にも規約を設ける
→ 「^」や「$」は、「¥A」「¥z」に
→ 複数の書き方ができる場合はどちらかに倒す

19. コーディング規約
悩んでいること
• 条件式「===」や「==」の使い分け
→ PHPの最大の弱点なので、うまく規約を作って回避したい
→ 可能な限り「===」を使う、「==」はなるべく使わないで果たしていいのか？
→ 空文字との比較「if (‘’ == $hoge) {」が、初心者には最強説？
• 変数の命名規則まで決めるべきか
• globalを使うことで、わかりやすくなるなら使ってもいいのでは
• requireやincludeを分岐の中で使ったり、requireするだけで実
行される命令文があるのは許されるか
• セキュリティ向上のための規約
→ 人様に見せるレベルではないので触れてないが、可能な限り規約で回避したい
→ さすがにコーディング規約とは別のレイヤーでは、という考えも？

20. まとめ
• コーディング規約を定めることは、少なくとも仕事でコ
ードを書く上では有用である
• スキルの低い人の救済が最大の目的
• 悩んでいることも多いので、まだまだこれから試行錯
誤中