Robert C. Martin先生のCleanCode第5章を読んだメモ。

書式化(第5章)の概要

  • 書式化の目的
    • コーディングスタイルのこと
    • 宗教戦争と片付けるべきではない。
    • 現在のちゃんと動くことよりも、将来的に役に立つ書式化の方が重要
    • 保守用異性と拡張性に影響を与え続ける
  • 縦方向の書式化
    • 厳格に定義すべきものではない。
    • 長いよりは短い方が良い。
    • 最大でも200〜500行ぐらいが良い。
  • 新聞に例える
    • 新聞は一番上に見出しがきてどんな内容なのか明らか。
    • ソースコードも同じように名前が単純で説明的でなければいけない。
    • 一番最初のファイルは高レベルの概念とアルゴリズムが書かれているべき。
    • ソースファイルの一番下は、最も低レベルの関数と詳細な記述がされている。
    • 新聞は多くの記事で構成されている。
    • もしも新聞が、事実、日付、名前の無秩序な塊で構成されていたら誰も読まない。
  • 垂直概念分離性
    • インポートの宣言、メソッド、パッケージ宣言などの間の改行を意識しなさい。
    • これらを垂直分離性と呼びます。
  • 垂直密度
    • ソースコードの各行が強く関連している場合、垂直密度が高い。
    • 垂直密度は各行の関連性を表す。
    • 無駄なコメントや、改行で密接な関係を崩さない。
  • 垂直距離
    • 密接に関連した概念は垂直方向に近い距離に置く
    • 相応な強い理由がなければ、関連を持った複数のファイルに分散するべきではない。
      • protectedな変数を避けるべき理由の1つ
    • 変数を宣言するときは、その変数が使用される場所となるべく近い位置で行う。
    • ループ内で利用する変数は、ループ内もしくは、ループの直前で宣言する。
    • インスタンス変数はクラスの頭で宣言する。
      • うまく設計されたクラスは、全てではないにしても多くのメソッドで利用されるため。
      • ハサミの規則はC++で採用されていることもあるが合理性はない。
      • メソッドとの間にメンバ変数宣言などがあると、これを見つけるのは困難。
    • 依存関数
      • 関数定義は、使われている場所のすぐ後に来ることが期待できる。
      • 下に下に呼び出していくようにすればモジュール全体を読むのがはるかに簡単になる。
    • 概念の密接な関係
      • 使われているすぐ後でなくとも、シンタックスシュガーや、オーバーライドなどは共通の命名体系を持っており、概念上密接な関係になる。
      • そのため、近くに置いた方が良い。
  • 垂直方向の並び順
    • 呼び出される側を下に置く。
    • モジュールのコードを高いレベルの概念から低いレベルへと流れるようにする。
  • 横方向の書式化
    • 行の幅はなるべく短くする。
    • 昔の80文字ルールは独断が過ぎる。
    • 100,120でも構わない。
    • Robert C. Martin的には120
  • 水平分離性と密度
    • 代入演算子の両脇にはスペースを置いて強調する。
      • 代入文は左辺と右辺が別々の概念なので。
    • 関数の括弧の間にはスペースを入れない。
      • 関数とその引数は強く関連しているため。
    • 演算子の優先順位を強調する目的でもスペースは使える。
      • (vertical * horizon * heigth) / 2 よりも (vertical*horizon*heigth) / 2 などの方が読みやすい場合がある。
      • ただし、多くのフォーマッターでは同じスペースを挿入する傾向がある。
  • 水平方向の位置合わせ
    • アクセス修飾子と変数名のスペースを統一にする的なあれ。
    • 有用ではない。
      • フォーマッターによって失われる。
      • 代入演算子などを見逃しがち
      • 型宣言などを見逃しがち
    • 位置合わせしなければならないほど大きいならファイルを分割した方が良さげ
  • インデント
    • インデントちゃんとしろ。
      • 人間には理解不能になる。
    • いかに短い関数でインデント規則を破りたくなったとしてもインデントし直しましょう。
  • ダミーのスコープ
    • while文やfor文の本体がダミーの場合。
    • セミコロンを別の行にインデントされると、非常に確認しにくい。
    • なるべく避ける
  • チーム規則
    • 自分の書式規則よりもチームの規則に従え
    • 各人が好き勝手にコードを書いたかに見えるような状態は好ましくない。
    • 好みと異なっても、チームのメンバーと決めたスタイルに従え。

感じたこと

動くことよりも、書式化の方が重要と考えるあたり、さすがだなと思った。
縦方向の書式化については100行ぐらいが好ましいのではないかと個人的には思う。
あと、水平方向の位置合わせについては、テストコードのDataProviderは、位置合わせした方が圧倒的に読みやすいとは思う。