エンジニア必読の１冊と言われる「リーダブルコード」を読んだので、初心者でもわかりやすいようにまとめました。
「良書」と言われている本ですが、エンジニアになりたての私には難しいところもあったんですよね。
そこで、他の方の記事を参考にしたり、会社の先輩エンジニアに聞きつつ理解を深めたので、記事にまとめました。
「リーダブルコード」を読んだ後に、補足的に読むと理解が深まると思います。
スポンサーリンク
【前提】１章 理解しやすいコード
まず前提として、誰でも理解しやすいコードを書きましょうということです。
他の人はもちろん、「未来の自分」が最短時間で理解できるように意識しようという点がポイントですね。
よく過去の自分が書いたコードが読めなくなることってありますよね。
第Ⅰ部 表面上の改善
まず最初のパートはソースコードの表面上の部分の話で、ここは初心者でも意識すべき項目です。
すぐに取り組めることなので、さっそく明日から実践してみましょう。
- 名前に情報を詰め込む
- 誤解されない名前
- 美しさ
- コメントすべきことを知る
- コメントは正確で簡潔に
それぞれ解説していきます。
２章 名前に情報を詰め込む
変数や関数、クラスすべてにおいて名前をつける時は、その名前に情報を詰め込みましょう。
大切なことは、変数などをパッと見てその名前が何を表しているのかがわかるような命名をすることです。
そのためには、以下のようなことが書かれていました。
- 気取った言い回しよりも明確で正確な単語を選ぶ
temp,it,retvalのような汎用的な名前はなるべく避ける- 変数名に大切な情報を追加する
例：ミリ秒を表す変数名には、後ろに_msをつける - スコープの大きな変数には長い名前をつける（短い名前はスコープが数行の変数につけるべき）
３章 誤解されない名前
ここも「名前に情報を詰め込む」と同じで、パッと見てすぐにわかる命名をしましょうということです。
名前が「他の意味と間違えられる事は無いだろうか？」と何度も自問自答し、最適な名前を付けましょう。
細かい具体例は、以下の通りです。
- 限界値を明確にするには、名前の前に
max_やmin_をつける - 範囲を指定する時は
firstとlastを使う - 包含/排他的範囲には
beginとendを使う - ブール値の変数は、頭に
is,has,can,shouldをつけることが多い
４章 美しさ
コードを書く時に美しさを意識すると、読みやすくなる上に、書いている自己満足度も上がるのでおすすめです。
一貫性と意味のあるやり方で、コードを整形するようにしましょう。
初心者でもすぐにできることは、以下の通り。
- 複数のコードブロックで同じようなことをしていたら、シルエットも同じようなものにする
- コードの「列」を整理すれば、概要が把握しやすくなる
- 意味のある順番を選んで、常にその順番を守る（ある場所でA,B,Cと並んでいたものを、他の場所でB,C,Aと並べない）
- 空行を使って大きなブロックを論理的な段落に分ける
初心者の私が特に「美しい」と思ってすぐに取り入れられたのは、２番目の項目です。
コードの「列」を整理するとは、縦の線をまっすぐにするとも言い換えられます。
本書の例を見てみましょう。
details = request.POST.get('details')
location = request.POST.get('location')
phone = request.POST.get('phone')
email = request.POST.get('email')
url = request.POST.get('url')＝（イコール）が揃っていて美しいですよね。
※デバイスによっては、揃って見えないこともあります。
こうすることで見た目もきれいな上に、ミスが見つけやすくなるというメリットがあります。
details = request.POST.get('details')
location = request.POST.get('location')
phone = equest.POST.get('phone')
email = request.POST.get('email')
url = request.POST.get('url')上記では、３番目でタイプミスをしていることがすぐにわかります。
５章 コメントすべきことを知る
コメントは重要ですが、何でもかんでもコメントを書けばいいということではありません。
コメントの目的は、コードの意図を読み手に理解してもらうことです。
まず、コメントを書くべきでは「ない」ことは、以下の通り。
- コードを見ればすぐにわかること
- ひどいコードを補うコメント（その場合はコメントを書くのではなく、コードを修正する）
続いて、コメントを書くべきポイントです。
- なぜ他のやり方ではなくこうなっているのか、自分の考えを書く
- コードを読んだ人が「えっ？」と思うところを予想してコメントをつける
- ファイルやクラスには全体像のコメントをつける
６章 コメントは正確で簡潔に
何をコメントに書くかを学んだ後は、コメントを正確で簡潔に書く方法の解説です。
ポイントは、小さな領域にできるだけ多くの情報を詰め込んだコメントを書くことです。
初心者でも意識できる具体的な方法は、以下の通りです。
- 「それ」や「これ」などの代名詞を避ける
- 関数の動作はできるだけ正確に説明する
- コードの意図は、詳細レベルではなく高レベルで記述する
- 多くの意味が詰め込まれた言葉や表現を使って、コメントを簡潔に保つ
「コードの意図は、詳細レベルではなく高レベルで記述する」というのは、コードの動作をそのまま書いているだけではダメということ。
本書に載っている、詳細レベルのコメントとは、以下のような感じです。
// listを逆順にイテレートするこれは、確かにコードをそのまま説明していますが、以下のようにコードが実現したいことを書くようにしましょう。
// 値段の高い順に表示する第Ⅱ部 ループとロジックの単純化
このパートでは、プログラムの「ループとロジック」について書いてあります。
複雑なループや巨大な式を見る時に増える「精神的な荷物」を減らすための方法です。
初心者でも、すぐに取り入れることができる部分が多いです。
- 制御フローを読みやすくする
- 巨大な式を分割する
- 変数と読みやすさ
それぞれ解説していきます。
７章 制御フローを読みやすくする
そもそも制御フローとは、「コンピュータがスクリプト内の文を実行する順序」のことです。
基本的に、コードは最初から順番に実行されますよね。
その順序を変えるものが、条件やループなどの制御フローです。
制御フローは、できるだけ自然にするようにしましょう。
制御フローを読みやすくするためのポイントは、以下の通りです。
- コードの読み手が立ち止まったり読み返したりしないように書く
- 行数を短くするよりも、他の人が理解するのにかかる時間を短くする
- ネストを浅くする
ぜひ覚えておくべき、条件式を書く際の具体的な書き方を本書のコードを引用します。
まず条件式の引数の並び順は、以下のように書きましょう。
- 左側：「調査対象」の式で、変化する
- 右側：「比較対象」の式で、あまり変化しない
具体的には、以下の式の方が、
if (length >= 10)以下の式より読みやすいですよね。
if (10 <= length)もう１つ、if/elseの並び順に関してのルールも覚えておきましょう。
- 条件は否定形よりも肯定形を使う
- 単純な式を先に書く
- 関心を引く条件や目立つ条件を先に書く
以下の２つのコードを比べた時に、前者の方が良いということです。
if (a == b) {
// 第1のケース
} else {
// 第2のケース
}if (a != b) {
// 第2のケース
} else {
// 第1のケース
}８章 巨大な式を分割する
巨大な式は、初心者はもちろん、ベテランでさえ理解が難しくなります。
なので、巨大な式は小さく分割しましょう。
分割する時のポイントは、以下の通りです。
- 最も簡単な方法は「説明変数」を導入すること
- 問題を否定したり、反対のことを考えてみて、複雑な論理条件は小さな文に分割する
説明変数というのは、例えば以下のようなコードがあったとします。
if line.split(':')[0].strip() == "root":説明変数を使うとは、以下のようにすることです。
username = line.split(':')[0].strip()
if username == "root":式が複雑にならないですし、理解しやすくなりますよね。
９章 変数と読みやすさ
この章は、少し難しいと感じました。
ポイントは、変数を適当に使うとプログラムが理解しにくくなるよ、ということです。
それを解消するために、以下のポイントが重要だそうです。
- 邪魔な変数を削除する：中間結果の変数など
- 変数のスコープをできるだけ小さくする
- 変数は１度だけ書き込む：変数を操作する場所が増えると、現在地の判断が難しくなる
変数はすぐに増えていずれ追えなくなってしまうので、なるべく減らして単純なものにしようということを理解すればOKだと思います。
第Ⅲ部 コードの再構成
このパートは、コードを大きく変更する技法の解説です。
難しい内容も含まれていましたが、ここでも初心者が使えることを中心にまとめていきます。
- 無関係の下位問題を抽出する
- 一度に１つのことを
- コードに思いを込める
- 短いコードを書く
それぞれ解説していきます。
10章 無関係の下位問題を抽出する
正直、初心者には理解できない部分が多かったです。
端的にまとめると、プロジェクト固有のコードから汎用コードを分離しようということです。
「このプログラムは、以前も書いたことがあるな」というのは、感覚としてわかりますよね。
大体のコードは、汎用化できます。
そうすることで、そのプログラム固有の小さな核に集中できますし、コードを再利用できるという利点があります。
11章 一度に１つのことを
１つのコードに、以下の全てが含まれていたら理解しづらいです。
- オブジェクトを生成して、
- データをきれいにして、
- 入力をパースして、
- ビジネスロジックを適用する
コードは、タスクを１つずつ行うようにしましょう。
そのために、読みにくいコードがあれば、そこで行われているタスクを全て列挙し、分割しましょう。
12章 コードに思いを込める
誰かに複雑な考えを伝える時には、簡単な言葉で説明する必要があります。
コードを読み手にプレゼンする場合も同様で、より簡単な言葉でコードを書く必要があるのです。
その時に効果的なのが、「解決策を言葉で説明する」ことです。
これは、私も経験があります。
「こういうプログラムを書きたい」と漠然と頭で考えるだけでなく、手順を１つずつ書き出していくと実装できた！という経験です。
本書でも、プログラムのデバッグに悩む学生が、部屋に置かれたテディベアに向かって最初に説明するだけで解決策が見つかるという事例が載っています。
特に初心者は、実装したいプログラムを１つずつ分解してみるのが有効だと思います。
その時に問題や設計をうまく言葉で説明できないのであれば、何かを見落としているか、詳細が明確になっていないということなのです。
13章 短いコードを書く
プログラマが学ぶべき最も大切な技能は、コードを書かない時を知るということです。
そのためには、以下のことを意識しましょう。
- 未使用のコードや無用の機能を削除する
- 最も簡単に問題を解決できるような要求を考える
- 定期的にすべてのAPIを読んで、標準ライブラリに慣れ親しんでおく
よく「車輪の再発明はするな」と言われることがありますよね。
すでに優秀なプログラマが書いたコードがライブラリにあるので、わざわざ１から書くなという教えです。
もちろん勉強のために自分で書いてみるのはいいですが、実務の場面でより短いコードを書くためには、車輪の再発明はするなということですね。
第Ⅳ部 選抜テーマ
最後のパートでは、以下のことを解説しています。
- テストと読みやすさ
- 「分／時間カウンタ」を設計・実装する
１つ目のテストに関しては、テストコードも読みやすさが大切であるということです。
ただ、私はまだテストコードというものを書いたことがないので、想像しにくかったです。
テストをすることがあれば、また読み返したいと思います。
２つ目に関しては実践編で、私は難しくて理解ができなかったので、割愛します。
ここが理解できなくても、そこまで影響はないはず。
【まとめ】初心者にもわかりやすく「リーダブルコード」をまとめてみた
今回は、名著「リーダブルコード」を会社の先輩にすすめられて読みました。
そして、読み終わった後にまとめ記事をいくつか見たものの、初心者用のまとめがなかったので自分でまとめてみました。
自分でまとめることで、より理解が深まり、知識が定着しました。
ただ、まとめ記事は多くありますが、ますは自分で読んでみることをおすすめします。
この本を読んで思ったことは、チーム全員が「リーダブルコード」読んで、コーディングのルールを明確にすべきだということです。
私が働いている会社では、明確なコーディングのルールがないんですよね。
徐々にコーディングルールを決めていき、途中からチームに参加した人でも迷うことなくコーディングできるというチーム作りをしたいです。
入社２か月目の新人ですが、そんな存在になっていきたいと思います。
以上です。
長々と最後まで読んでいただき、ありがとうございました。
最後に宣伝
ココナラで、コーディングの相談を受け付けています。
- CSSが上手く作れない
- JavaScriptが思ったように動かない
- ブログのデザインを修正したい
- 勉強中でわからないところがあるから教えてほしい
このようなお悩みを解決していますので、「こんなの解決できる？」ということがあったら、ぜひ質問だけでも以下のリンクよりどうぞ。
コメント