###概要
全体の内容をさっと把握したい時などに、お使い下さい。
##リーダブルコードとは
表紙には以下のように記載されています。
***より良いコードを書くためのシンプルで実戦的なテクニック ***
##1章 理解しやすいコード
- コードは理解しやすくなくてはならない
- コードは他人が最短時間で理解できるようにかかなければならない
##2章 名前に情報をつめこむ
- 明確な単語を選ぶ
不明確なget~等は非推奨
- tmpなどの汎用的な名前は避ける
意味があるときは別
- 具体的な名前を使って物事を詳細に説明する
- 変数名のフォーマットで情報を伝える
ミリ秒の場合は _ms
- スコープの大きな変数には長い名前を付ける
逆にスコープが小さいときは短い名前
- 大文字やアンダースコアに意味を付与する
##3章 誤解されない名前
- 名前が「他の意味と間違われることはないだろうか」と自問自答する
- 最善の名前は誤解されない名前である
- 単語に対するユーザーの期待に合わせる
- get()やsize()は軽量なメソッドが期待されている
悪い例
filter()
選択するor除外する
Clip(text, length)
文字を切り詰めるor最後から文字を削除する
単位も複数考えられる
bool値の名前
否定的な名前はつけないよう注意
bool disable_ssl = false;
良い例
限界値を明確にする
名前の前に「_min」・「_max」を付ける
範囲を指定する
firstとlastを用いる
包含/排他的範囲の場合
beginとendを用いる
bool値の名前
頭にis/has/can/shouldをつける
否定形よりも肯定形で書く
bool use_ssl = true;
##4章 美しさ
- 優れたコードは「目に優しい」
- 余白・配置・順序に気を使う
- 読み手がなれているパターンと一貫性のあるレイアウトを使う
- 似ているコードは似ているようにみせる
- 関連するコードをまとめてブロックにする
- コードの「列」を整形すれば、概要が把握しやすくなる
- 意味のある順番を選んで、常にその順番を選ぶ
- 空行を使って大きなブロックを論理的な「段落」をつける
##5章 コメントすべきことを知る
- コメントの目的とは、コードの意図を読み手に理解してもらう事
- コメントすべきでは「ない」こと
- コードからすぐに抽出できること
- ひどいコードを補う「補助的コメント」→コメントではなくソースを修正すべき
- 記録すべき自分の考え
- なぜコードが他のやり方ではなくこうなっているのか
- コードの欠陥をTODO等の気泡を使って示す
- 定数にまつわる背景
- 読み手の立場になって考える
- 読み手が「えっ?」と思うところを予想してコメントを書く
- ファイルやクラスには「全体像」をコメントする
- コードブロックにコメントを付けて概要をまとめる
- ライターズブロックを乗り越える
- 以下、手順
- 頭の中にあるコメントをとにかく書き出す
- コメントを読んで改善が必要な部分を書き出す
- 改善する
##6章 コメントは正確で簡潔に
- コメントの質をあげるために
- 曖昧な代名詞「これ」などは使わない
- 関数の動作はできるだけ正確に説明する
- コメントに含める入出力の実例は慎重に選ぶ
- よくわからない引数にはインラインコメントを使う
- 多くの意味が詰め込まれた言葉や表現を使ってコメントを簡潔に保つ
##7章 制御フローを読みやすくする
- 条件やループなどの制御フローはできるだけ「自然」に
- 条件式の引数並び順
例1:
if(length > 10)
例2:
if(10 < length)
-
例1の方が読みやすい
左側:調査対象の式、変化する。右側:比較対象の式、変化しない -
if/else文のブロックの並び順
- 肯定形・単純・目立つものを先に処理する
-
非推奨な要素
- 三項演算子(aa?bb:cc)
- do/whileループ
- goto
-
ネストを浅くする
- 失敗する場合を出来るだけ早めに関数から返せばよい
- ループ内部のネストを削除する
-
continue
を用いる
-
- 関数の上部で単純な条件を先に処理しておく
##8章 巨大な式を分割する
- 説明変数
- 式を簡単に分割するには、式を表わす変数を使う
- 要約変数
- 式を説明しなくても複数回使用する際は、小さい名前に置き換えておく
- ド・モルガンの法則をつかう
- コードの主要な「概念」を読み手が認識しやすくする
##9章 変数と読みやすさ
- 変数を適当に使うとプログラムが理解しにくくなる
- 変数が多いと追跡が難しくなる
- スコープが大きいと、スコープを把握する時間が長くなる
- 頻繁に変更されると現在ではの値を把握するのが難しくなる
- 対応策
- 邪魔な変数を削除する
中間結果などは不要
- できるだけ小さいスコープとする
変数のことがみえる行数を減らす
- 1度だけ書きこむ変数を使う
constやfinalなど
- 邪魔な変数を削除する
##10章 無関係の下位問題を抽出する
- プログラム固有のコードから凡用コードを分離する
- ほとんどのコードは凡用化できる
- しかし、やりすぎは注意して
##11章 一度に1つの事を
- コードは1つずつタスクを行うようにしなければならない
- 「関数は1度に1つの事しかしてはいけない」のアドバイスと似ている内容
- 読みにくいコードがあれば、そこで行われているタスクを全て列挙し、全体像をみよう
##12章 コードに思いを込める
- 簡単な言葉で説明する
- ラバーダッキングしてみよう
##13章 短いコードを書く
- できるだけコードを書かない
- 不必要な機能をプロダクトから削除する。過剰な機能は持たせない
- 最も簡単に問題を解決できるような要求を考える
- 定期的にAPIを読んで、標準ライブラリに慣れておく
##14章 テストと読みやすさ
テストとはテストコードのこと
- 他のプログラマが安心してテストの追加や変更ができるようにテストコードを読みやすくする
- できるだけ簡潔に
- 失敗したらわかりやすいエラーメッセージを
- 単純な入力値を使う
- テストに説明的な名前をつけて何をテストしているのかわかりやすくする
##感想
- 自分がレビューする際に、上記の内容を確認し、指摘するよう心掛ける
- 自分がレビューしてもらう際は、上記の内容を指摘されないように心掛ける