My Favorite Things - Coding or die.

とある技術者の経験記録、的な。

リーダブルコード - The Art of Readable Code まとめ

良いコードを書くのは得意だという自負があったのでなんとなく読むのをスルーしていたが、改めて読んでみると勉強になる部分がとても多かった。特に「最短時間で理解できるコードが読みやすいコードだ」という一文にはとても感銘を受けた。あとは自分の中でも答えが出ていなかったものに対して、明確な回答が用意されていてよかった。
 
以下、自分が重要だと思ったことを少しずつまとめていく。
 
1章
  • コードは理解しやすくなければいけない
  • コードは他の人が最短時間で理解できるように書かなければいけない

 
第I部 表面上の改善
 
2章 名前に情報を詰め込む
  • 明確な単語を選ぶ(get → fetch / download、stop → pause / kill)
  • 抽象的な名前よりも具体的な名前を使う(--run_locally → —use_local_database)
  • 名前に情報を追加する(id → hex_id)
  • 値の単位(start → start_ms)
  • その他の重要な属性を追加する(plaintext_password、unescaped_comment、html_utf8)
  • スコープが小さければ短い名前でもいい
    // コードを理解するのに必要な情報がすぐそばにあるからだ。
  • 不要な単語を投げ捨てる(ConvertToString() → ToString())
  • 名前のフォーマットで情報を伝える(コーディング規約での命名規約とか)
 
3章 誤解されない名前
  • filter() → select() / exclude()
  • Clip(text, length) → remove(text, length) / truncate(text, length)
  • 限界値を含めるときはminとmaxを使う
  • 範囲を指定するときはfirstとlastを使う
  • 包含/排他的範囲にはbeginとendを使う
  • ユーザの期待に合わせる(getMean() → computeMean()、size() → countSize())
 
4章 美しさ
  • なぜ美しさが大切なのか?
    → 見た目が美しいコードのほうが使いやすいのは明らかだ。考えてみれば、プログラミングの時間のほとんどはコードを読む時間なのだッ!
  • 一貫性のある簡潔な改行位置
  • (ヘルパー)メソッドを使った整列
    // コードの「見た目をよく」すれば、表面上の改善だけではなく、コードの改善もできる
  • 縦の線をまっすぐにする
  • 整列すべきなのか?
    // ぼくたちの経験では、プログラマが心配するほどの手間にはならない
    // もし手間になるようだったら、そのときは止めればいい
  • 宣言をブロックにまとめる
    // 論理的なグループに分けてあげるといいだろう
  • コードを「段落」に分割する
    • 似ている考えをグループにまとめて、他の考えと分ける
    • 視覚的な「踏み石」を提供できる
    • 段落単位で移動できるようになる
  • 個人的な好みと一貫性
    → 一貫性のあるスタイルは「正しい」スタイルよりも大切だ。
 
5章 コメントすべきことを知る
  • コメントの目的は、書き手の意図を読み手に知らせることである。
  • コードからすぐにわかることをコメントに書かない。
    • 例:Accoutクラスの定義
  • ひどい名前はコメントをつけずに名前を変える
    • 優れたコード > ひどいコード + 優れたコメント
  • 自分の考えを記録する
    • コードが期待ない理由をコメントに書いてもいい
    • コードの欠陥にコメントをつける
      • その欠陥を文書化することを恥ずかしがってはいけない
  • 定数にコメントをつける
    • なぜその値を持っているのかという「背景」が存在する場合が多い
    • 頭のなかで考えていたことを記録するのが大切
  • 読み手の立場になって考える
    • 質問されそうなことを想像する
    • // ベクタのメモリを開放する(「STL swap技法」で検索してみよう)
    • 「このコードを見てビックリすることはなんだろう?」
    • 「どんなふうに間違えて使う可能性があるだろう?」
    • 要約コメント(全体像についてコメントする)
 
6章 コメントは正確で簡潔に
  • コメントは領域に対する情報の比率が高くなければいけない
  • コメントを簡潔にしておく
    • // CategoryType -> (score, weight)
      typedef hash_map<int, pair<float, float> > ScoreMap;
  • 曖昧な代名詞を避ける(それ)
  • 歯切れの悪い文章を磨く(によって優先度を変える → の優先度を高くする)
  • 関数の動作を正確に記述する
    • // このファイルに含まれる改行文字(’\n’)を数える。
      int CountLines(string filename) { … }
  • 入出力のコーナーケースに実例を使う
    • // 実例:Strip(“abba/a/ba”, “ab”)は”/a/“を返す
      String Strip(String src, String chars) { … }
  • コードの意図を書く(listを逆順にイテレートする → 値段の高い順に表示する)
  • 情報密度の高い言葉を使う(キャッシュ、正規化)