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

12,371 views

Published on

0 Comments
9 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
12,371
On SlideShare
0
From Embeds
0
Number of Embeds
3,247
Actions
Shares
0
Downloads
52
Comments
0
Likes
9
Embeds 0
No embeds

No notes for slide

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

  1. 1. チーム開発を うまく行うためのコーディング規約論 [PHP編]株式会社インフィニットループ ke-tai.org 松井健太郎
  2. 2. 自己紹介• 株式会社インフィニットループ代表• ケータイプログラマのための情報サイト「ke-tai.org」管理人• コーラが好き
  3. 3. 本日の内容• コーディング規約とは• コーディング規約はなぜ必要か• 目的と考え方• 具体的なコーディング規約• コーディング規約で悩んでいること※ご注意 この資料内で具体例として取上げているコーディング規約は、 あくまで弊社で勝手に定めているものです。 案件内容や構成スタッフによって最適解は異なります。
  4. 4. コーディング規約とはWikipedaより• プログラミング作法(Programming style)、コー ディング標準(Coding Standards)とも呼ばれる• プログラムのソースコードを書くときの規則やガ イドライン群を指す。特定のプログラミング作法 に従っていれば、コードを読んで理解するのが容 易になり、間違う可能性も減らせるとする思想。
  5. 5. コーディング規約はなぜ必要か(1) 外注など不特定多数の人が参加するにつれ、 いろんなコードを書く人が増えてくる → なんでもグローバル変数に格納する人 → GOTOを使う人 → 関数を使わずにincludeで処理を書く人【マネージャーにとっての利点】• 品質の安定化に繋がる• 他のスタッフに引き継ぎがしやすい
  6. 6. コーディング規約はなぜ必要か(2)【プログラマにとっての利点】• 他人が書いた部分のコードが読みやすい• 「気持ち悪い」を減らせる• grepしやすい• ハマりどころを回避できる → PHPがダメ言語だと言うのなら、規約で可能な限り回避したらいいじゃない
  7. 7. 目的と考え方• 個人の限界を越えるため→ 規模の大きい案件では、チーム開発が必須 (例:ソーシャルゲームなど)→ 個人よがりの考えは無視し、最大公約数的なポイントを模索する• スキルの低い人の救済を目指す→ ハマりどころを意識しなくて済むように→ 迷った時はスキルの低い人向けに合わせる• 開発効率をあげる→ 可読性やgrepしやすさを意識する→ 2通り以上の書き方が出来るものは、1種類に統一する→ 開発効率を落とさぬ範囲内で、ちょっと厳しすぎるかな、くらいを目指す• 不毛な宗教戦争は起こさない→ 機能性(バグの起きにくさなど) > シンプルさ・わかりやすさ > 気持ち悪さ→ 我々は仕事でコードを書いている、仕事である以上コーディング規約を守ろう→ 自分のスタイルで書きたい人はご自宅で
  8. 8. 具体的なコーディング規約(1) 原則• PEAR標準コーディング規約をベースにしているhttp://pear.php.net/manual/ja/standards.php• PHPの偉い人たちが考えたものなので、さすがよくできている• マニュアルなどで目にしているせいか、意外と違和感がなくなじみやすい• これをベースに使いづらい箇所を直し、細かい要素を追加していく
  9. 9. 具体的なコーディング規約(2) 文字コード、基本ルール• 文字コードは「UTF-8(BOMなし)」で記述する• 改行コードには「LF改行」を使う• 「<?」(short_open_tags)ではなく「<?php」を利用する → XMLとの共存を行いやすくするため• 「?>」(閉じPHPタグ)は省略し記述しない → 不要な改行が出力されるトラブルを防ぐため• タブ幅は4とする → スペースを使ったインデントや8タブなどは使わない 宗教戦争ポイント! 宗教戦争ポイント! ポイント
  10. 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. 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. 12. 具体的なコーディング規約(5) 分岐・条件式• ifはリテラルを前にして記述する(=を一つしか付けず代入となって 気付きづらいというミスを起こさないため) 宗教戦争ポイント! 宗教戦争ポイント! ポイント × if ($a == hoge) { ○ if (hoge == $a) {• 「and, or」を使い、「&&, ||」は使わないこと 宗教戦争ポイント! 宗教戦争ポイント! ポイント• 三項演算子は使わない 別にどちらでもいいけど、 $res = (0 == $value ? true : false); どちらかに統一したかった• 「{」「}」(波カッコ)の省略はしないこと if (0 == $value) return true;
  13. 13. 具体的なコーディング規約(6) コメント• コメントについての考え方 → コメントは、他人のため、もしくは2年後の自分のために書くこと → このコードを引き継ぐのは、自分より数段スキルが低い技術者であると思うこと → 何をしているかはコードを見ればわかるので、なぜそうしているのかを書くこと → 口語体やくだけた言葉でコメントを書くのは絶対に止める。プロ意識を持つこと → 他人がレビューする際にまず見るのはコメント   コメントがいい加減なコードは絶対に信頼を得られないということをよく知ること• コメントは「//」または「/* ~ */」を使い、「#」は使わないこと
  14. 14. 具体的なコーディング規約(7) コメント• 多数の行に渡りコメントアウトする際には原則「//」を使うこと。 「/* */」を使うときはgrepでわかるようにするためJavaDoc形式 のように頭に*をつけること 誤った例: 以下のような形だとgrepした際にコメントアウトされていることがわからない /* $res1 = sampleFunction(1); $res2 = sampleFunction(2); */ 正しい例: // $res1 = sampleFunction(1); // $res2 = sampleFunction(2);
  15. 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. 16. 具体的なコーディング規約(9) 関数複数の書き方ができるものは、なるべくまとめていく• キャスト演算子をやめる → (int)の代わりに、intvalを使うなど• empty()は使わず、isset()を使う → empty()とisset()は挙動が違う、これを毎回説明するくらいなら使用禁止にする• 正規表現はpreg系を使うなどなど
  17. 17. 具体的なコーディング規約(10) その他• 無名関数はなるべく使わない → 初心者には理解できない恐れ → 無名関数でなくてはならないケースがそれほど無い• 日付計算の”-1 month”などはやめる → できればDatetimeなどを使うのがいい• gotoやglobalは使わない• 時間系の定義は、書く順番を決める define(HOGE_HOGE_INTERBAL, 60 * 60 * 24 * 3); ※その他いろいろありますが、書ききれないので省略
  18. 18. コーディング規約 今後• 使わない関数をもう少し吟味していく• SQLの書き方にも規約を設ける → SQLは可読性が重要な箇所• 正規表現にも規約を設ける → 「^」や「$」は、「¥A」「¥z」に → 複数の書き方ができる場合はどちらかに倒す
  19. 19. コーディング規約 悩んでいること• 条件式「===」や「==」の使い分け → PHPの最大の弱点なので、うまく規約を作って回避したい → 可能な限り「===」を使う、「==」はなるべく使わないで果たしていいのか? → 空文字との比較「if (‘’ == $hoge) {」が、初心者には最強説?• 変数の命名規則まで決めるべきか• globalを使うことで、わかりやすくなるなら使ってもいいのでは• requireやincludeを分岐の中で使ったり、requireするだけで実 行される命令文があるのは許されるか• セキュリティ向上のための規約 → 人様に見せるレベルではないので触れてないが、可能な限り規約で回避したい → さすがにコーディング規約とは別のレイヤーでは、という考えも?
  20. 20. まとめ• コーディング規約を定めることは、少なくとも仕事でコードを書く上では有用である• スキルの低い人の救済が最大の目的• 悩んでいることも多いので、まだまだこれから試行錯誤中

×