色々と思うことを連々と
RE: 堅牢なコーディングルールを策定する方法(1) - 都元ダイスケ IT-PRESS
コーディングルールとはなんじゃらほい
そんな「コーディング」に一貫性を持たせるのがコーディングルールだ。
もちろん質の悪い方向に一貫性を持たせてはいけないので、質を良くする方向の一貫性を持たせるためにコーディングルールを作っていくことになると思う。
どのような観点でルールを作成するかは、たぶん次のような分類になるんじゃないかなーと。
- 処理には影響しないが、見た目には大きな差となって映るものの統一
- インデントの種類と深さを統一する
- 括弧の位置、全体のレイアウトを統一する
- 80桁での折り返し*1
- 命名規約
- 使う単語の統一
- ミクロ単位での処理の統一
- 値が想定通りかどうかを事前にチェックすることを推奨する、など
- 環境独自の不具合やボトルネックを回避するためのメモ
それぞれのルールについて「しなければならない」「するべきである」「してもよい」「しないほうがよい」「しないべきである」「してはならない」という段階があるはず。なんかコーディング規約なるものを見る限り「しなければならない」「してはならない」しか使われてないものが多いんだけど、妙に窮屈なんだよねー
バグがどこにあるのか
このコードは、実行するとNumberFormatExceptionでプロセスが終了する訳ですが。このコードにバグはあるだろうか？ あるとしたら、どこがバグなのだろうか？
間違いなくバグとして計上できる箇所が一点ほど。俺がレビュアーとしてこのコードを見るならば、
- ドキュメントが記述されていない
ことを真っ先に指摘するかな、と。
ドキュメントが記述されていないために、他の色々な点が明確になっていない*2ために、責任のなすりつけが起きているのだと思う。
その他、指摘するならば
- setBar, getBar のシグネチャが不適切。単純な ValueObject として Foo をデザインするならば bar に合わせた int 型でなくてはならず、そうでないならば名称を変えるべき。
- 数値に変換できない文字列を setBar に渡した場合、例外を投げて終了することは適切である可能性が高い。想定外のデータが混入した場合に Foo として迅速に安全側に倒すためにも、NumberFormatException は望ましい結果である可能性がある。
とかとか。
入出力を明確にしないと、どんなコードも書けないですよ。万一書けたとしたら、それはすなわちバグを意味します。とか。
