思索日記

本を読んで思ったことを書いてます。

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

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック(以下リーダブルコード)は、読みやすいコードを書くためのヒントを紹介したオライリーの名著です。2019年9月時点で23刷まで行っているベストセラー本です。 プログラムを書く際に気を付けるべきコメントの書き方・変数の付け方などの書式上の注意点から、うまく関数を切り分けてコード全体の見通しを良くする方法まで、たくさんのヒントが紹介されています。読みやすいコードはより良いコードだという信念をもって書かれていて、「それがなぜ良いコードなのか」も含めて良くわかる1冊です。

みどころ・おすすめのポイント

読みやすい

本書は量が少なく原著(英語)で200ページしかありません。私は空いた時間に眺めただけで読めて、延べで3~4時間もかからなかったと思います。
またサンプルコードの言語に偏りがなく、どの言語使いでも読みやすいと思います。

また、日本語訳は、先輩や友人からアドバイスを受けるような語り口で親しみやすいというのも読みやすさの要因だと思います。ちなみに私はこのタイプちょっと苦手。

内容はめっちゃ濃いのに簡潔な文でまとめられていて、それでいて理解もしやすいです。カロリーが多いのに飲みやすい。タピオカみたいですね。

具体的なヒントがたくさん

読みやすいコードを書くための具体的なヒントがたくさん入っています。まあそういう趣旨の本なんですが。それで、その間に芯の通った指標が標語のような形で入っています。
「こうしたらいいよ。こういう場合はこうしたらいい。でも、この指針とこの指針は競合する場合がある。そういうときは、基本原則の〇〇〇に立ち返ってどちらがいいか判断しよう。」こんな具合です。
これってどこかで見たことあるタイプの本だなあと思ったら、高校数学参考書のチャート式に似ているんですよね。例題はたくさんあって、問題タイプ網羅的に見えるけれども、簡潔な標語で問題の解き方の共通化をはかる。

徐々にレベルアップ

簡単ですぐできるものからスタートして、徐々に取り組むのに本気度が必要なものにレベルアップしていく流れになっています。だから手に取りやすい。
単純にわかりやすい名前やコメントなどの「書式論」で終わりじゃなくて、コードを分割したりネストを整理したりと、「論理的にわかりやすくするためにはどうすればいいか」にしっかりと分量が割かれています。
それから、後半は本気度が必要ってだけで、別に難しいわけじゃないのもポイントです。いや、本当は難しいことをやっているのかもしれないけど・・・筆者の説明がわかりやすすぎるのかもしれません。

好きなエピソードなど

本書は各章独立して読むことができます。どの章も読みやすいコードを書くためのヒントとして有用ですが、その中から自分に刺さった章を2つ紹介します。

説明変数・要約変数

8章より。 コードを短くするのは楽しいのでついやってしまうし、余計な変数を無くすことはいつでもいいことのように見えるけれど、「不必要な」変数をあえて入れることでわかりやすさがアップすることがある。

Before

if (File.Exists(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location) + string.Format("\\{0}.{1}", _FILE_NAME_HEAD, _FILE_EXTENSION))
{
     File.Delete(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location) + string.Format("\\{0}.{1}", _FILE_NAME_HEAD, _FILE_EXTENSION))
}

After

string dirName = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
string fileName = string.Format("\\{0}.{1}", _FILE_NAME_HEAD, _FILE_EXTENSION);
string fileFullPath = dirName + fileName;
if(File.Exists(fileFullPath))
{
    File.Delete(fileFullPath);
}

これはこの本に書いてあって思ったことではないですが:
いやいや、元のコードも十分わかりやすいよ?読解力ないんじゃないの?と思うこともできるかもしれない。けれども、元のコードがわかりづらいという人も結構いて、そういう人と仕事をする機会は意外と結構ある。というのを肝に銘じておこう。

早期return + try-finally

早期returnしたくない人を実際見たことが無いので 早期returnを使わないダメな例を挙げることが難しいのですが、 感銘を受けたのはtry-finallyと早期returnの組み合わせをうまく使うことで、後処理をfinallyの中にきれいにおさめることができそう、ということです。

try-catch-finally句内のreturnについて - Qiita

すすめたい人

読むべき読者は、間違いなくプログラマーです(当然ですが)。プログラム書かない人は、読んでも何のことかわからないと思います。
プログラマーの中でも特に、仕事でプログラムを書く人、新人プログラマーが読むべきだと思います。あとは、コードレビューする立場になった人とか。
プログラムを書くけれども仕事では書かないよ、趣味で書くよ、勉強中だよという人は、頑張って読む必要はあんまりないと思います。読まない方がいいとは言わないけど、いずれ職業としてプログラムを書くならその時に読んだ方がいいと思います。

私が手に取ったきっかけ

  • なんとなくオライリー本を読んでみようと思ったので。
  • ベストセラーなのは知っていたから。
  • 特定の言語や分野よりも、全般的に使える技術本を読みたかったので。

奥付

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック
2012年
Dustin Boswell, Trevor Foucher著
角征典
オライリー・ジャパン発行