リーダブルコードを読んだら恥ずかしくなってきた話

リーダブルコード読んでみました。
元Googleの方が書いた本ということもありいろいろとお勉強になることが多いと思いまして。
結論から言うと、「めっちゃ勉強になって、自分の書いてきたコードが恥ずかしくて人に見せられなくなった」
という感じですかね。
プログラマとしてキレる人の目線を少し感じられました。
わかりやすい話で、ベテランエンジニアからすると当然って思うことばかりかもしれませんが、
少なくとも会社に入りたての新人や、駆け出しプログラマは読むといいんじゃないでしょうか。
読んで自分に参考になった点を箇条書きでまとめます。



名前に情報を詰め込む

* 明確な単語を選ぶ
  send ⇒　deliver, dispatch, announce, etc...
  find ⇒ search, extract, locate
  start ⇒ launch, create, begin, open

* 汎用的な名前は避ける
  tmp, retvalみたいなものは避け、エンティティの値や目的を表現した名前を選ぶ
  スコープが小さければ例外的に使ってもOK
  単語補完機能があるから、長い名前を入力するのは問題じゃない

* 値の属性を追加する
  単位：　**_ms, **_mb, **_kbps, etc
  その他：　**_utf8, **_urlenc

* 名前のフォーマットで情報を伝える
  クラス名はCamelCase
  変数名はlower_separated
  定数はkConstantName
  クラスのメンバ変数は member_

コメントすべきことを知る

  自分の考えを記録する
  既知の不具合や試行錯誤の結果、挙動に関する評価をコメントする
  コードの欠陥にコメントを付ける
  プログラマがよく使う記法

  記法 典型的な意味
  - TODO   :  あとで手を付ける
  - FIXME   : 既知の不具合があるコード
  - HACK    : あまりきれいじゃない解決策
  - XXX       : 危険。大きな問題がある

* 定数にコメントをつける
  定数が何をするのか、なぜその値を持っているのかという背景を説明する

* 要約コメント
  関数内部の大きな塊に対して、全体像に関するコメントをしておく。

制御フローを読みやすくする

  do/whileループは避ける
  if, while, forと異なり、条件が下にくるので少し不自然
  
* ネストを浅くする
  ネストの深いコードは理解しにくい
  早めに返すことでネストを削除orコードをクリーンにできる
  失敗ケースは早めにreturnし、タスクを出来るだけ早く完了させる
  continueでループ内部のネストを削除

* 巨大な式を分割する
  説明変数を導入する
  式を変数に代入しておき、簡潔な名前で式を説明することでコードを文書化する
  主要な概念を読み手が認識しやすくなる

  ド・モルガンの法則を使う

  論理式を簡潔に

変数と読みやすさ
  変数のスコープを縮める
  if文内部のスコープ
  グローバル変数は読む人を不安にさせる
  定義の位置を下げる(C99, C++には先頭で定義する制約が無い)
  constやfinalは使えるときは使う