チーム開発をうまく行うためのコーディング規約論
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 10,552 views

 

Statistics

Views

Total Views
10,552
Views on SlideShare
7,383
Embed Views
3,169

Actions

Likes
7
Downloads
43
Comments
0

6 Embeds 3,169

http://ke-tai.org 3160
http://twitter.com 3
https://twitter.com 3
http://www.slideshare.net 1
http://webcache.googleusercontent.com 1
http://asklife.info 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • チーム開発を うまく行うためのコーディング規約論 [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の偉い人たちが考えたものなので、さすがよくできている• マニュアルなどで目にしているせいか、意外と違和感がなくなじみやすい• これをベースに使いづらい箇所を直し、細かい要素を追加していく
    • 具体的なコーディング規約(2) 文字コード、基本ルール• 文字コードは「UTF-8(BOMなし)」で記述する• 改行コードには「LF改行」を使う• 「<?」(short_open_tags)ではなく「<?php」を利用する → XMLとの共存を行いやすくするため• 「?>」(閉じPHPタグ)は省略し記述しない → 不要な改行が出力されるトラブルを防ぐため• タブ幅は4とする → スペースを使ったインデントや8タブなどは使わない 宗教戦争ポイント! 宗教戦争ポイント! ポイント
    • 具体的なコーディング規約(3) 改行ルール• ソースコードが横に長い場合でも改行はしない 宗教戦争ポイント! 宗教戦争ポイント! ポイント基本: 改行なし例外1: 条件文を書くときは改行可if ($hogehoge == $pugepuge and $hogehoge == $pugapuga or $hogehoge == $pegopego and $hogehoge == $chomechome) { 理由: ・画面幅は人それぞれ ・何文字で改行するかの意見が皆バラバラで結 論がでなかった例外2: 配列への代入の時は改行可 ・イヤならエディタ側で改行すればいいじゃない$hoge = array( abc => def, ghi => jkl, mno => pqr‘); ※関数呼び出しの際にも改行したいとの声があったが、   それは関数の設計が間違っているのでは?ということになった
    • 具体的なコーディング規約(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) {• コメント × //コメント文字列 ○ // コメント文字列
    • 具体的なコーディング規約(5) 分岐・条件式• ifはリテラルを前にして記述する(=を一つしか付けず代入となって 気付きづらいというミスを起こさないため) 宗教戦争ポイント! 宗教戦争ポイント! ポイント × if ($a == hoge) { ○ if (hoge == $a) {• 「and, or」を使い、「&&, ||」は使わないこと 宗教戦争ポイント! 宗教戦争ポイント! ポイント• 三項演算子は使わない 別にどちらでもいいけど、 $res = (0 == $value ? true : false); どちらかに統一したかった• 「{」「}」(波カッコ)の省略はしないこと if (0 == $value) return true;
    • 具体的なコーディング規約(6) コメント• コメントについての考え方 → コメントは、他人のため、もしくは2年後の自分のために書くこと → このコードを引き継ぐのは、自分より数段スキルが低い技術者であると思うこと → 何をしているかはコードを見ればわかるので、なぜそうしているのかを書くこと → 口語体やくだけた言葉でコメントを書くのは絶対に止める。プロ意識を持つこと → 他人がレビューする際にまず見るのはコメント   コメントがいい加減なコードは絶対に信頼を得られないということをよく知ること• コメントは「//」または「/* ~ */」を使い、「#」は使わないこと
    • 具体的なコーディング規約(7) コメント• 多数の行に渡りコメントアウトする際には原則「//」を使うこと。 「/* */」を使うときはgrepでわかるようにするためJavaDoc形式 のように頭に*をつけること 誤った例: 以下のような形だとgrepした際にコメントアウトされていることがわからない /* $res1 = sampleFunction(1); $res2 = sampleFunction(2); */ 正しい例: // $res1 = sampleFunction(1); // $res2 = sampleFunction(2);
    • 具体的なコーディング規約(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; }
    • 具体的なコーディング規約(9) 関数複数の書き方ができるものは、なるべくまとめていく• キャスト演算子をやめる → (int)の代わりに、intvalを使うなど• empty()は使わず、isset()を使う → empty()とisset()は挙動が違う、これを毎回説明するくらいなら使用禁止にする• 正規表現はpreg系を使うなどなど
    • 具体的なコーディング規約(10) その他• 無名関数はなるべく使わない → 初心者には理解できない恐れ → 無名関数でなくてはならないケースがそれほど無い• 日付計算の”-1 month”などはやめる → できればDatetimeなどを使うのがいい• gotoやglobalは使わない• 時間系の定義は、書く順番を決める define(HOGE_HOGE_INTERBAL, 60 * 60 * 24 * 3); ※その他いろいろありますが、書ききれないので省略
    • コーディング規約 今後• 使わない関数をもう少し吟味していく• SQLの書き方にも規約を設ける → SQLは可読性が重要な箇所• 正規表現にも規約を設ける → 「^」や「$」は、「¥A」「¥z」に → 複数の書き方ができる場合はどちらかに倒す
    • コーディング規約 悩んでいること• 条件式「===」や「==」の使い分け → PHPの最大の弱点なので、うまく規約を作って回避したい → 可能な限り「===」を使う、「==」はなるべく使わないで果たしていいのか? → 空文字との比較「if (‘’ == $hoge) {」が、初心者には最強説?• 変数の命名規則まで決めるべきか• globalを使うことで、わかりやすくなるなら使ってもいいのでは• requireやincludeを分岐の中で使ったり、requireするだけで実 行される命令文があるのは許されるか• セキュリティ向上のための規約 → 人様に見せるレベルではないので触れてないが、可能な限り規約で回避したい → さすがにコーディング規約とは別のレイヤーでは、という考えも?
    • まとめ• コーディング規約を定めることは、少なくとも仕事でコードを書く上では有用である• スキルの低い人の救済が最大の目的• 悩んでいることも多いので、まだまだこれから試行錯誤中