コーディング規約再考
http://d.hatena.ne.jp/bleis-tift/20090804/1249389793の話。
確かに元のコーディング規約は突っ込みどころが多い。Javaの規約をそのまま持ち込むという時点で規約項目の検討が甘いことは想定できるし、実際の突っ込みも納得できるものが多い*1。
このコーディング規約についてメタレベルの突っ込みを入れてみよう。
チェック法の規定がない。
コーディング規約を守っているかどうかをチェックする方法を規定していない。典型的な検査法にはそれぞれ問題がある。
- 目視検査
- 圧倒的に労力の無駄。
- 抜き取り検査
- 品質保証であって品質保障ではない。
- 自動検査
- 品質保障として使えるが、判定条件を作れるかが疑問*2。
想定される最悪の事態は「何か問題が発生してから遡及してチェックする」という手法だ。品質保証ですらない。
設計に関する内容が含まれている。
設計に関する内容というのは、例えばモジュールの外部仕様だ。外部仕様は設計段階で決まっているべきという点は同意してもらえると思う。実際、そうなっていないことも多いとしても、そのようなところは同時に結合段階で苦労していることだろう。
開発工程自体の設計が良くない状態であるにも関わらず、その問題点を肯定した規約を作るというのは理解できない。
「自転車置場の議論」が多い。
人が集まると、なぜかどうでもいいようなことほど議論が紛糾してしまう傾向がありますが、このような現象のことを、FreeBSD のコミュニティでは自転車置場の議論 (bikeshed discussion) と呼んでいることを知りました。
(http://0xcc.net/blog/archives/000135.html)
「自転車置場の議論」になる条件は、もう少し細かく表現すると次のようになるのではないか。
- 「複数の選択肢から選ぶ」形式の議論である。
- それぞれの選択肢は大した違いがない。
- 参加者の判断基準が統一されていない。
つまり、
- 自分で考える必要がない。
- 「間違い」が存在しない。
- 論点のレベルが間違っている*3。
ということになるのだと思う。
その他。
- 優先順位
- 規約の見直し
- etc.
〆。
「コーディング規約」についてはformatツールとlintツールで規定すれば十分だろう。「設計規約」については設計言語の定義から進めないとならないかもしれない*4。
