Table of Contents

• 名前に情報を詰め込む
• 誤解されない名前
• 美しさ
• コメントすべき事を知る
• コメントは正確で簡潔に
• ループとロジックの単純化
• 巨大な式は分割する
• 変数と読みやすさ
• 無関係の下位問題を抽出する。
• 1度にひとつの事を
• テストと読みやすさ

名前に情報を詰め込む

• 変数や関数の目的や値を表す名前にする。(名前に情報を詰め込む。)
• getやtmpなどのような汎用的な名前は避け、明確な単語を選ぶ。
• Tmpは関数内での一時的な保管変数としてなら問題ない。
• ループイテレータでI,k等を使用しても問題ない。
• 絶対に知らせたい大切な情報があれば、単語を変数名に追加する。
• 長い名前を避ける。不要な単語は投げ捨てる。
• スコープが小さければ短い名前でも良い。
• プロジェクト固有の略称を使用しない。

誤解されない名前

• 名前が他の意味と間違えられることはないだろうかと何度も自問自答する。
• 限界値を含めるときはminとmaxを使用する。
• 範囲を指定するときはfirstとlastを使用する。
• 包含、排他的範囲にはbeginとendを使用する。
• Bool値の変数にはis,has,can,should等をつけてわかりやすくする。
• 単語に対するユーザーの期待に注意する。例えば、getやsizeには軽量なメソッドが期待されている。

美しさ

一貫性のあるスタイルら正しいスタイルよりも大切。

• 読み手が慣れているパターンと一貫性のあるレイアウトを使用する。
• 似ているコードは似ているように見せる。
• 関連するコードをまとめてブロックにする。

コメントすべき事を知る

• コメントの目的は書き手の意図を読み手に知らせる事である。
• コードからすぐにわかることをコメントに書かない。
• 酷い名前はコメントをつけずに名前を変える。
• 自分の考えを記録する。
• コードの欠陥にコメントをつける。
• 定数にコメントをつける。
• ハマりそうな罠を告知する。
• 全体像のコメントをする。

コメントは正確で簡潔に

• コメントは領域に対する情報の比率が高くなければならない。
• あいまいな代名詞を避ける。(それ、これ)
• 関数の動作を正確に記述する。
• メソッド入出力の具体例を使用する。
• コードの具体的な意図を書く。
• 多くの意味が込められた言葉や表現を使ってコメントを簡潔に保つ。

ループとロジックの単純化

条件やループなどの制御フローは出来るだけ自然にする。

• Ifの左は調査対象の式(変化する)で、右は比較対象の式(変化しない)を書く。
• 条件は否定形よりも肯定系を使用する。
• 単純な条件を先に書く。
• 関心を引く条件や目立つ条件を先に書く。
• 行数を短くするよりも他の人が理解するのにかかる時間を短くする。
• 関数内でガード節で早く返す。
• ネストを浅くする。早めに返して、ネストを削除する。
• ループ内部のネストを削除する。

巨大な式は分割する

• 式を表す説明変数を使用する。

変数と読みやすさ

• 変数が多いと変数を追跡するのが難しくなる。
• スコープが大きいとスコープの把握の時間が長くなる
• 変数が頻繁に変更されると現在の値を把握するのが難しくなる。
• 役に立たない一時変数は削除する。
• 変数のスコープを縮める。
• 変数を操作する場所が増えると、現在値の判断が難しくなるので、変数は一度だけ書き込むようにする。

無関係の下位問題を抽出する。

• 無関係の下位問題とは個別にテストできて、将来的に再利用可能な処理。
• プロジェクトから独立したライブラリのような汎用コードを沢山作成する。
• 既存のインターフェイスが汚ければ自ら簡潔なラッパーを作成する。
• 小さな関数を作りすぎないように注意する。

1度にひとつの事を

• 関数は一度にひとつの事を行うようにする。

テストと読みやすさ

• 他のプログラマが安心してテストの追加や変更ができるようにテストコードを読みやすくする。
• 大切ではない詳細はユーザーから隠し、大切な詳細は目立つようにする。
• 最小のテストを作る。
• エラーメッセージを読みやすくする。
• コードを完全にテストする最も単純な入力値の組み合わせを選択する。
• 1つの機能に複数のテストをする。ソートのテスト、重複のテスト等。
• テストの機能に名前をつける。