リーダブルコードを読んだ

今回読んだ本
リーダブルコード

読みやすさの基本定理がわかる

コードを綺麗に保つことでバグの発見や、開発の効率化が望める
また他のプログラマとの共有も容易になる
常に一歩下がってこのコードは理解しやすだろうかと自問自答して考える

名前について

短いコメントのようなもの（名前に情報を埋め込む)

• 明確な単語を選ぶ
• 汎用的な名前を避ける
• 抽象的な名前よりも具体的な名前を選ぶ
• 長い名前を避ける
• 不要な単語を投げ捨てる（ConverToStringをToStringの様に）
• 限界値にはminとmaxを使う
• 範囲を指定するときにはfirstとlastを使う
• 排他的範囲にはbeginとendを使う

コードの美しさに気を配る

見た目が美しいコードのほうが使いやすい

• 一貫性のある簡潔な改行位置
• メソッドを使った整列
• 縦の線をまっすぐにする
• 個人の好みより一貫性

コメントの書き方

コメントは書き手の意図を読み手に知らせる情報である

• 自分の考えを記録する
• コードからすぐわかることを書かない
• ひどい名前はコメントをつけずに名前を変える
• コードの欠陥にコメントをつける(TODO)
• 読み手の立場になって考える(前もって予測する)
• 動作を正確に伝える
• コードの意図を書く
• それやこれなどの代名詞は避ける

ロジックの単純化を行う

単純なロジックになることで問題点の改善などがしやすく理解しやすくなる

• 単純な条件を先に書く
• 関心を引く条件や目立つ条件を先に書く
• 巨大な式を分割する
• 論理式を綺麗に書き直す
• 変数が多いと追跡するのが難しくなる
• 変数を頻繁に変更されると現在の値を把握するのが難しくなる
• スコープを単純にする
• 汎用的なコードを作る
• 一度に１つのタスクを適用する
• ライブラリを活用する
• 短いコードを書く
• 重複コードを削除する
• 未使用な機能や無用の機能を削除する 　

テストについて

• テストを読みやすくする
• 最小のテストを心がける
• テストを読みやすくするとテスト以外のコードも読みやすくなる
• 他のプログラマが安心してテストを追加変更できるようにする
• エラーメッセージを読みやすくする
• テストしやすいコード設計する
• テストに名前をつける

自身が良いコードを書くためのプロセスについて

実際に書き他の方の意見を聞き、その都度改善しどのようにしたら綺麗なコードが書けるか覚える。身につける。（体に覚えさせる）これができると当たり前になると思う。

今後もプログラマである以上、多数のプログラマとプロジェクトを回していくと思うし、運用などにも関わると思う。その際に見やすく、バグが発見しやすく、カスタマイズしやすいようなコードを書けるよう自身でも綺麗なコード、読みやすいコード意識して書いていければと思う。