新米エンジニアの筆者が、エンジニア界では有名な著書「リーダブルコード」を読み終えて学んだことを記録しておこうと思います。
リーダブルコードを一言で言うならば、「自分のコードを他人が読んだ時、理解するまでの時間が最短になる為のコーディング手段」を提示してくれる書籍でした。
筆者自身の理解が浅いこともあり、コードの「あるべき姿」がわからない状態での出会いだったので、本書を読み終えた後のリファクタリングにも大いに役立ちました。
本ブログでは、「その後のコーディングで役立った事」と、「各章のポイント」の２つを記載していこうと思います。
1. その後のコーディングで役立った事
項目としては、全部で３つあります。・変数、メソッドの名前を強く意識するようになった
・メソッドの機能を単一化すること
・最も読みやすコードは何も書かれていないコード
###変数、メソッドの名前に意図を込めるようになった###
読み返した際、「頭の中でコードを読み返す」のと「コードを見て読み取る」のでは後者の方が間違えもなく短時間でコーディングが進みました。
小さなことですが、メソッド名を number() => getNumber、saveNumber に変えてみたり、定数を大文字にすることを意識的に使い分けました。
###メソッドの機能を単一化、できるだけ小さく保つこと###
筆者の中で大きかったのは、「同じ処理を複数書かなくなった、無駄なコードが減った」です。
筆者だけかもしれませんが「〜という機能がほしい」と思った時はいつも１つのメソッドで機能を実現しようとしてしまいがちでした。
しかし、その思考が和らいだおかげで、大きい単位のメソッドを書いている時には気が付かなかった毎回書いていた数行のコードにも意識が向くようになり、
結果、全体のコード量も減って同じ処理をベタ書きすることが減りました。
###最も読みやすコードは何も書かれていないコード###
どういうエンジニアになりたいか？という目標がなかった筆者を、「書かないエンジニア」・・・は無理だとして、「最小限のコードで最短時間をもって機能を実現できるエンジニア」という方向に向かわせてくれるきっかけになった言葉です。(13章の冒頭に出てきます）
これに関しては、まだ実現もしくは体験できたことはありません。ただ、目標かつ日々意識するようになったこととして書かせていただきました。
2. 各章の紹介
[目次]
１章 理解しやすいコード第１部 表面上の改善（２章〜６章）
２章 名前に情報を詰め込む ３章 誤解されない名前 ４章 美しさ ５章 コメントすべきことを知る ６章 コメントは正確で簡潔に第２部 ループとロジックの単純化（７章〜９章）
７章 制御フローを読みやすくする ８章 巨大な式を分割する ９章 変数と読みやすさ第３部 コードの再構築（１０章〜１３章）
１０章 無関係の下位問題を抽出する １１章 一度に一つのことを １２章 コードに思いを込める １３章 短いコードを書く第４部 選抜テーマ（１４章〜１５章）
１４章 テストと読みやすさ １５章 「分/時間カウンタ」を設計・実装する１章：理解しやすいコードとは
「コードは他の人が最短時間で理解できるように書かなければならない」
・他人が読みやすいコードを作れる <=> 頭の中で理解し、整理できている状態 ・5000行より2000行のコード ・無理やりな１行よりは、分解した２行、コメント１行＋１行のコード2章：名前に情報を詰め込む
具体的な名前を使って物事を詳細に説明する
・Get()よりDownloadPage() ・tempやretvalなど汎用的な名前を避ける ・大文字やアンダースコアなどに意味を込める：クラス変数とローカル変数の区別化３章：誤解されない名前
曖昧な名前はさける＝具体的な名前を選定
・filter()よりもselect(), exclude() ・特徴を付加：_max, _min, _ms, _raw ・BOOL値の場合：is, has, can, should ・否定形の名前を使わない４章：美しさ
コードの列を整理すれば概要が把握しやすくなる
・意味のある空行、改行、順番を選んで常にその順番を守る ・ある場所でABCのように並んでいたものを、他の場所でBCAの要に並べてはいけない ・アルファベット順、重要度の高い順、対応するHTMLのinput順など ・空行を使って大きなブロックを論理的な段落にわける５章：コメント
**コメントすべきでないことを知る（コメントには書かないこと）**
・コードからすぐ抽出できる事は書かない ・Account(); // コンストラクタ・・・は不要 ・ひどいコードを補助するコメントよりもコードを修正する**コードを書いている時の自分の考えを記録する（コメントとして書くべきこと）**
・コードの欠陥をTODOやXXXなどの記法を使用する ・定数にはコメントしてもよい -> const int MAX_RSS_SUBSCRIPTIONS = 1000; // 合理的な限界値。人間はこんなに読めない。**読み手の立場になって何が必要かを考える（思考）**
・質問されそうなことを想像する ・平均的な読み手が驚くような動作は文章化しておく ・ファイルやクラスには「全体像」のコメントをする６章：コメントは正確で簡潔に
・「それ」「これ」は使わない ・コメントに含める意図は詳細レベルではなく高レベルで記述する ・多くの意味が詰め込まれた言葉や表現を使ってコメントを簡潔に保つ ・よくわからない引数にはインラインコメントを使う（/* XXX */）７章：制御フローを読みやすくする
・比較（while (a < b)）を書く時には変化する値を左に、より安定した値を右に配置する ・if/else分のブロックは適切に並び替える（肯定形、単純、目立つもの） ・参考演算子、do/whileループ、gotoはなるべく代替案で補う ・深いネストになる時は失敗を先に書く（continueなどで抜けるなど）８章：巨大な式を分割する
・式を表す「説明変数」「要約変数」を利用してコードを簡潔化する ・コードの主要な「概念」を読み手が認識しやすくなる ・ド・モルガンの法則を利用： if ( ! ( a && ! b ) ) => if ( !a || b )９章：変数と読みやすさ
・邪魔な変数を削除する（一度しか使っていない、複雑な式を分割していない変数） ・変数のスコープを出来るだけ小さくする ・なるべく定数を使う（static,sonstなど）10章：無関係の下位問題を抽出する
・プロジェクト固有のコードから汎用コードを分離する ・ライブラリやヘルパー関数を作っていく11章：一度に一つのことを
タスクは小さくできる
・コードでは一度に一つのことを行う ・読みにくいコードはタスクを列挙して、別の関数やクラスに分類できるタスクを探す12章：コードに思いを込める
・ロジックを明確にする（！をなるべく使わない） ・ライブラリを知る ・プログラムを簡単な言葉で何か・誰かに説明する手法（ラバーダッキング） -> 例えば声に出す、テディーベアに説明する、友達同士で説明し合うなど13章：短いコードを書く
・コードを小さく保つ（維持する） ＝ 重複コードの削除、サブプロジェクトへの分割 ・過剰な機能は持たせない ・定期的に全てのAPIを呼んで、標準ライブラリに慣れ親しんでおく
14章：テストと読みやすさ
・テストのトップレベルは出来るだけ簡潔にする、入出力のテストコードは１行で記述できるといい ・テストが失敗したらバグの発見や修正がしやすいようなエラーメッセージを表示する ・テストに有効な最も単純な入力値を使う ・テスト関数に説明的な名前をつけて何をテストしようとしているのかを明らかにする、Test1(),ではなく、Test_<関数名>_<状況>
15章：「分/時間カウンタ」を設計実装する
本書で習ったことをカウンタのプログラムを用いて復習していく。 名前、コメントの改善、コードの共通化（重複の削除、汎用化）、機能の単一化など。 実際にコードが整理されていく感覚、わかりやすく表現されるのを具体的に体験する。
以上です。
何か、読者の方々の意識に残ることがあれば幸いです。
ありがとうございました。