Tbpgr Blog

Employee Experience Engineer tbpgr(てぃーびー) のブログ

書籍 リーダブルコード

概要

書籍 リーダブルコードに関するメモ。
全てをカバーせず、自分の中で新たに学ぶことやまとめ直しておきたいことのみを抜粋します。
また、例示するサンプルも写経せずに出来るだけ自分で考えたサンプルにします。

各章

1章 理解しやすいコード

自分以外の開発者もしくは半年後の自分が最も短い時間で理解できる
コードを意識すること。

2章 名前に情報を詰め込む

汎用的すぎる用語は使わない、内容を表す命名を行うなどごく一般的な内容。

4章 美しさ

美しいコードは読みやすいだけではなく、結果としてバグの発見や
リファクタリングのきっかけとなる。
ここで例示されている、「コードの位置を揃える」は好みではありません。

def aaa        = "aaa";
def bbbbbbbbbb = "bbb";

など。コーディング本体とは別にコード整形の手間がかかるから。例えばここに
bbbbbbbbbbより長い名前の変数ccc・・・が追加された場合追加対象がcc・・・にも
関わらずaaaとbbb・・・の位置もメンテナンスする必要が出てしまう。

処理の塊ごとに改行を増やすのはよくやります。

5章 コメントすべきことを知る

コメントが不要な明白なコードにはコメントが不要。
何かしら補足情報が必要になる背景のあるコードや
処理の要約など読み手のコードリーディングを助けるコメントは必要。

6章 コメントは正確で簡潔に

曖昧な表現をなくし、場合によっては例を示す。
意味を凝縮した用語がある場合は、その用語によってコメントを簡潔にする。

7章 制御フローを読みやすくする

三項演算子
ガード節

8章 巨大な式を分割する

説明変数

9章 変数と読みやすさ

不要な変数の削除、変数のスコープを狭くする、などごく一般的な物を中心とした内容。

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

コードの高レベルの目標とは異なる下位レベルの問題を抽出すること。
このことを意識することで、コード自体がビジネスロジックの本質のみを表し
共通的な処理は汎用的なライブラリとして抽出し、別プロジェクトへの転用などに利用出来る。

ここでは、Martin Fowlerのリファクタリング本やプロダクティブ・プログラマーなどでも
触れられているComposed Methodの重要性にも触れている。

11章 1度に1つのことを

つまり単一責任の原則(SRP= Single Responsibility Principle)ってことで。

12章 コードに思いを込める

ただ単に処理が正しく動作するだけではな、読み手(保守対象者)に意味が伝わるような
コードにすること。
達人プログラマーのラバーダッキングの話もあり。
(結局は達人プログラマー読んでると読み飛ばせる内容が多いってことですが・・・)

13章 短いコードを書く

YAGNIの話。共通化の話。ライブラリの知識をもつことについて。
ということでこの辺も色々書籍を読んでいれば新たな情報はなし。

14章 テストと読みやすさ

テストコード自体の可読性の話とかは意外と他の書籍などに載っていないので
いい話かも。とは言え、JavaならJUnit4の形式やRubyならRSpecなどに触れていれば
自然とこの本に書いてあるような内容はカバーされていて、
可読性の高いテストになっているだろう。

15章 実例

実際の開発を考慮した実例。こういうパターンの説明って技術書にあまりないから貴重かも。

参考書籍

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

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