08-ボーイスカウト・ルール

「プログラマが知るべき97のこと」の８つ目のエピソードは、コードの美しさに関する話です。ボーイスカウト・ルールに習ってコーディングをするならば、「モジュールをチェックアウトする際には、必ずチェックアウト時よりも美しくする」というルールを課そうという話です。
本文にも書いてあるように、少しでも改善をする姿勢があれば、少なくともチェックアウト時よりも汚くすることがなければ、モジュールの品質は低下することはありません。少しの改善を続けていくことで、少しづつモジュールの品質があがることになります。本文に書かれている例以外に考えつくのはこんな所です。

• 変数名を適切なものに変更する
• テストコードを追加する
• ブロックネストを減らす
• メソッドを分割する
• クラスを分割する
• 共通処理をユーティリティクラスに移す
• JavaDoc（ドキュメント）を見直す

特に単体テストとドキュメント類は急いで実装を進めているとおろそかにしがちな部分です。必要最低限のテストとドキュメントで進めていく事も現実として多いでしょう。自分もそうです。ですが、ちょっとだけ時間が余った時など、コードを見てテストを追加してみたり、ドキュメントを整備したりするように心がけています。
しかし、１つだけ問題が、それも非常に大きな問題があります。「美しく」することは重要なのですが、なにが「美しい」かの基準は人によって全く異なるという事です。さらにいえば、それが「美しい」か否かを判断するにはスキルが必要です。そもそも「美しさ」は不要と思う人*1もいます。
例えば、新しい処理を追加したコードをレビューした所、こんな状況だったとします。

void someLogic() {
  for (Foo foo: fooList) {
      // 処理
      if (foo.isPoo()) {
          break;
      }
  }
}

void someLogic() {
  for (Foo foo: fooList) {
      // 処理
      if (foo.isPoo()) {
          // 仕様変更で追加 2010.12.28
          // MoreLogicが必要ならば、追加処理を行う
          if (foo.needMoreLogic()) {
             // Pooのリストを取得し、ループする
             for(Poo p: foo.getPooList()) {
                // Hogeでない場合は処理しない
                if (p.isHoge()) {
                   // 追加処理
                 }
             }
          }
          // 追加ここまで
          break;
      }
  }
}

あなたはどう感じるでしょう？

1. 何か問題でも？
2. 動くならいいんじゃない？
3. ちょっと見ずらいけど許容範囲
4. ないわー
5. えっ、このコードのレベル低すぎ・・・

プログラマが知るべき97のこと

*1:プログラマとはいいません