チーム開発をうまく行うためのコーディング規約論

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

自己紹介

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

本日の内容
• コーディング規約とは
• コーディング規約はなぜ必要か
• 目的と考え方
• 具体的なコーディング規約
• コーディング規約で悩んでいること

※ご注意
この資料内で具体例として取上げているコーディング規約は、
あくまで弊社で勝手に定めているものです。
案件内容や構成スタッフによって最適解は異なります。

コーディング規約とは
Wikipedaより

• プログラミング作法（Programming style）、コー
ディング標準（Coding Standards）とも呼ばれる

• プログラムのソースコードを書くときの規則やガ
イドライン群を指す。特定のプログラミング作法
に従っていれば、コードを読んで理解するのが容
易になり、間違う可能性も減らせるとする思想。

コーディング規約はなぜ必要か(1)
　外注など不特定多数の人が参加するにつれ、
いろんなコードを書く人が増えてくる
→　なんでもグローバル変数に格納する人
→　GOTOを使う人
→　関数を使わずにincludeで処理を書く人

【マネージャーにとっての利点】
• 品質の安定化に繋がる
• 他のスタッフに引き継ぎがしやすい

コーディング規約はなぜ必要か(2)

【プログラマにとっての利点】

• 他人が書いた部分のコードが読みやすい
• 「気持ち悪い」を減らせる
• grepしやすい
• ハマりどころを回避できる
→　PHPがダメ言語だと言うのなら、規約で可能な限り回避したらいいじゃない

目的と考え方
• 個人の限界を越えるため
→　規模の大きい案件では、チーム開発が必須　（例：ソーシャルゲームなど）
→　個人よがりの考えは無視し、最大公約数的なポイントを模索する

• スキルの低い人の救済を目指す
→　ハマりどころを意識しなくて済むように
→　迷った時はスキルの低い人向けに合わせる

• 開発効率をあげる
→　可読性やgrepしやすさを意識する
→　2通り以上の書き方が出来るものは、1種類に統一する
→　開発効率を落とさぬ範囲内で、ちょっと厳しすぎるかな、くらいを目指す

• 不毛な宗教戦争は起こさない
→　機能性（バグの起きにくさなど）　＞　シンプルさ・わかりやすさ　＞　気持ち悪さ
→　我々は仕事でコードを書いている、仕事である以上コーディング規約を守ろう
→　自分のスタイルで書きたい人はご自宅で

具体的なコーディング規約(1)
原則
• PEAR標準コーディング規約をベースにしている
http://pear.php.net/manual/ja/standards.php

• PHPの偉い人たちが考えたものなので、さすがよくで
きている

• マニュアルなどで目にしているせいか、意外と違和感
がなくなじみやすい

• これをベースに使いづらい箇所を直し、細かい要素を
追加していく

文字コード、基本ルール
• 文字コードは「UTF-8(BOMなし)」で記述する
• 改行コードには「LF改行」を使う
• 「<?」(short_open_tags)ではなく「<?php」を利用する
→　XMLとの共存を行いやすくするため

• 「?>」（閉じPHPタグ）は省略し記述しない
→　不要な改行が出力されるトラブルを防ぐため

• タブ幅は4とする
→　スペースを使ったインデントや8タブなどは使わない宗教戦争ポイント！
宗教戦争ポイント！
ポイント

改行ルール
• ソースコードが横に長い場合でも改行はしない
ポイント

基本：　改行なし

例外1：　条件文を書くときは改行可
if ($hogehoge == $pugepuge and $hogehoge == $pugapuga or
$hogehoge == $pegopego and $hogehoge == $chomechome) {
理由：
・画面幅は人それぞれ
・何文字で改行するかの意見が皆バラバラで結
論がでなかった
例外2：　配列への代入の時は改行可・イヤならエディタ側で改行すればいいじゃない
$hoge = array(
'abc' => 'def',
'ghi' => 'jkl',
'mno' => 'pqr‘
);

※関数呼び出しの際にも改行したいとの声があったが、
　それは関数の設計が間違っているのでは？ということになった

スペースのあけ方
• 代入や演算、文字列の連結
× $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) {

• コメント
× //コメント文字列
○ // コメント文字列

分岐・条件式
• ifはリテラルを前にして記述する（=を一つしか付けず代入となって
気付きづらいというミスを起こさないため）宗教戦争ポイント！
ポイント

× if ($a == 'hoge') {
○ if ('hoge' == $a) {

• 「and, or」を使い、「&&, ||」は使わないこと
ポイント

• 三項演算子は使わない別にどちらでもいいけど、
$res = (0 == $value ? true : false); どちらかに統一したかった

• 「{」「}」（波カッコ）の省略はしないこと
if (0 == $value) return true;

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

• コメントは「//」または「/* ～ */」を使い、「#」は使わないこと

コメント
• 多数の行に渡りコメントアウトする際には原則「//」を使うこと。
「/* */」を使うときはgrepでわかるようにするためJavaDoc形式
のように頭に*をつけること

誤った例：
以下のような形だとgrepした際にコメントアウトされていることがわからない
/*
$res1 = sampleFunction(1);
$res2 = sampleFunction(2);
*/

正しい例：
// $res1 = sampleFunction(1);
// $res2 = sampleFunction(2);

コメント
• 処理ブロックに対しコメントを付ける場合の例
// 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;
}

関数
複数の書き方ができるものは、なるべくまとめていく

• キャスト演算子をやめる
→　(int)の代わりに、intvalを使うなど

• empty()は使わず、isset()を使う
→　empty()とisset()は挙動が違う、これを毎回説明するくらいなら使用禁止にする

• 正規表現はpreg系を使う
などなど

その他
• 無名関数はなるべく使わない
→　初心者には理解できない恐れ
→　無名関数でなくてはならないケースがそれほど無い

• 日付計算の”-1 month”などはやめる
→　できればDatetimeなどを使うのがいい

• gotoやglobalは使わない
• 時間系の定義は、書く順番を決める
define('HOGE_HOGE_INTERBAL', 60 * 60 * 24 * 3);

※その他いろいろありますが、書ききれないので省略

コーディング規約
今後
• 使わない関数をもう少し吟味していく
• SQLの書き方にも規約を設ける
→　SQLは可読性が重要な箇所

• 正規表現にも規約を設ける
→　「^」や「$」は、「¥A」「¥z」に
→　複数の書き方ができる場合はどちらかに倒す

コーディング規約
悩んでいること
• 条件式「===」や「==」の使い分け
→　PHPの最大の弱点なので、うまく規約を作って回避したい
→　可能な限り「===」を使う、「==」はなるべく使わないで果たしていいのか？
→　空文字との比較「if (‘’ == $hoge) {」が、初心者には最強説？

• 変数の命名規則まで決めるべきか
• globalを使うことで、わかりやすくなるなら使ってもいいのでは
• requireやincludeを分岐の中で使ったり、requireするだけで実
行される命令文があるのは許されるか

• セキュリティ向上のための規約
→　人様に見せるレベルではないので触れてないが、可能な限り規約で回避したい
→　さすがにコーディング規約とは別のレイヤーでは、という考えも？

まとめ
• コーディング規約を定めることは、少なくとも仕事でコ
ードを書く上では有用である

• スキルの低い人の救済が最大の目的
• 悩んでいることも多いので、まだまだこれから試行錯
誤中

チーム開発をうまく行うためのコーディング規約論

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (11)

Similar to チーム開発をうまく行うためのコーディング規約論

Similar to チーム開発をうまく行うためのコーディング規約論 (15)

More from Kentaro Matsui

More from Kentaro Matsui (16)

チーム開発をうまく行うためのコーディング規約論