書籍「リーダブルコード」

前々から読もうと思っていた本が会社に届いたので読んでみた。
テスト駆動開発と同じく、手元に置いておきたい本なので結局購入しそう･･･

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

---

感想

全体を通して良いコード(≒可読性・保守性が高いコード)の書き方についての本。
普段から「良いコード」を意識している人には目新しい内容はないかも。
(例えば命名ルール、ネストを浅くするには、など)
ただ日頃あまり明文化しない勘・コツの類がコンパクトに文章化されているので、知識の整理や振り返り、人に教える教材としてとても良い。

特にチームで開発する場合、「経験に基づく勘・コツ」は三者三様だし文章化できていない暗黙知の場合が多い。あるべき姿や言葉遣いを統一する拠り所として、全員で一読すると捗りそう。
図や例を多様して200ページという軽さも、サラッと読んで勧められるので良ポイント。

学ぶためにも復習のためにも、ぜひ一度読んで欲しい良書。
良いコード・良い設計のための本ということで、テスト駆動開発も合わせてオススメ。

ymegane88.hatenablog.com

---

書籍の概要

項目

• 命名規則
• コーディングスタイル
• コメント
• ロジック・制御フロー
• リファクタリング
• テストの書き方

コンセプト

• 他人が理解しやすいように書く
• 他人とは6ヶ月後の自分かもしれない
• 名前や順番に意味を持たせる
• 小さいことはいいこと(スコープ、関数の大きさ、記述量)

---

初めて知った手法・考え方

以下、本書で初めて知った方法や意識したことがなかった方法を抜粋。

命名規則

名前に単位や属性を付加する

• より明確な単語を選ぶ。
  例曖昧なGetHogeではなく具体的な動作を示すDownloadHoge, FetchHogeとする。
  単語の選択に困ったら類語辞典で近い意味の英単語を探す。
  Qiitaやブログに頻出英単語まとめ記事がたくさんあるので、参照する。
• size_mb, delay_secsのように単位をつける。
• plaintext_passwordのように平文であることを明示する。
• 書式の事例紹介：クラスのメンバ変数の末尾に_をつける(例：size_, name_)

「良いコード」の最も基礎的な部分だけど、要するに「知ってるか知らないか」なのでレベルを上げるには時間と根気と良いコードを読む機会が必要そう。

コメントの書き方

• 名前付き引数風コメント
  名前付き引数が使えない言語で引数の意味を明示する方法の案。

Connect(timeout = 10, use_encryption = False) # 名前付き引数

Connect(/*timeout =*/10, /*use_encryption =*/false) //名前付き引数風コメント

• 引数に関するコメントの書き方例

// Connect(timeout, use_encryption)
//          [secs]   [boolean]
con = Connect(10, false)

• 自分の考えを記録する
  例：// ◯◯という理由で〜〜というロジックを採用した
• 定数にコメントをつける
  なぜその固定値を選んだか根拠を記す。
• 挙動を厳密かつ完結に記す
  △：//ファイルの行数を数える
  　　･･･空ファイルは？hello\n\r cruel\n world\rは何行？
  ◯：//ファイルに含まれる'\n'を数える
• 入力のコーナーケースの実例を記す

上記のようなコメントを規約としてある程度強制すると、命名や設計を明確・簡潔に作るよう促せそう。
簡潔・明快な日本語を書く能力＝国語力なので、命名と同じく結局は教養的なものが求められるので 一朝一夕では鍛えられない。根気よくコードレビューしながら育てるしかない？

制御フロー・ロジックの単純化

• ネストを浅くする
• ループや関数を早く抜ける(if, elseを浅くする)
• スコープは極力小さくする
• 三項演算子、Do Whileなどパッと見で分かりづらい処理は必要性を考える

変数やコメントの章と比べると技法的な話は少なめで、一般的なお作法という感じ。
読み手に対してなにかを解釈したり覚えたりという負荷をかけないこと。

リファクタリング

• 関数を小さく分割して汎用化する
  • 複数の機能を個別機能に分割する
  • 上位の機能を支える下位の機能を抽出して分割する

こちらも一般的なお話。
小さく分割されていて、かつ処理フローがシンプルだと読みやすい上にテストしやすい。

その他

• 意図が分かるテストを書く
  ソースコードと同様に意味のある名前をつけ、意図が分かる値をテストする。
• 標準ライブラリを知る
  標準ライブラリを知っておけば余計なコードやテスト、ドキュメントを書かずに済む.

---

まとめ

上記以外のことや上記の詳細も書かれているが、基本的には下2つが基本軸。

• いい名前を付けること
• 短いコードを書くこと

これらを実現するためのアイデア・ベストプラクティス集という感じ。
本書をすんなり理解できるチームなら本書を参考に開発チーム全体で「良いコード」の認識を共有すると捗りそう。

あるいはこれから学ぶという人も、最初のチュートリアルや簡単なモノづくりが一段落したら早い内に読んで、その後本書の内容を意識しながらコーディングすると良いコードを書く「良い習慣」が身につくと思う。

最初に書いたとおり、サラッと読めるのに学びと再発見の多い良い本でした。