「リーダブルコード」を読んだ感想・まとめ

こんにちわ。Webエンジニアになりたいモリヤス(@_moriyas）です。

プログラマーになったら必読書と言っても過言ではない「リーダブルコード」

今回は個人的に目から鱗だった部分、簡単にまとめていきたいと思います！

※ほんの一部の紹介なので、ぜひ自分で購入して読みましょう！

※以下は、僕の解釈が入っており、本来の意図違うことを書いている可能性がありますのでご注意ください！

短いコードよりも理解しやすいコードにする

1章では、「とにかく理解しやすいコードを書け！！」「他の人が読んだ時に理解する時間が短いほど良いコード」的なことが述べられています。

できるだけ短く簡潔なコードにすれば良いと思っている人がいるけど、だからと言って理解しやすいかと言われるとそれは違う場合もあります。

「他の人が理解できるって、誰が得するんだよ？このコードを使っているのはオレだけなんだぞ！」でもね、例え君ひとりのプロジェクトだったとしても、この目標には取り組むだけの価値があるんだ。「他の人」というのは、自分のコードに見覚えのない6ヶ月後の「君自身」かもしれない。君のプロジェクトに途中から誰かが参加しないとも言い切れない。「使い捨てのコード」が他のプロジェクトで再利用される可能性だってある。

（P3)

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

僕自身、これまで既存Webサービスの改修の業務や、僕以外が作ったWebサイトの改修などしたことがあります。

そんな時に、よくわからんコードが書いてあると「なんじゃこれ！！」と叫ぶもんな！

なんなら、自分で書いたコードを、1年くらい経ってから改修した経験があるけど、訳わからんコード書いていた自分にキレたもんな〜ww

確かにすぎる！d(￣ ￣)

本の中で具体例として挙げられていたのが「三項演算子」。

if文を1行で書ける優れものだけど、条件が長く複雑なものであった場合とんでもなくわかりにくくなるよな〜

これまで、「コードはできるだけ短くした方が良いよな〜」なんて考えていたけど、本当にそれが理解しやすいのかを考えてコードを書いていこうと思いました！

getじゃあわからんて！！

2章では「命名するときに曖昧な言葉を使うな！とにかく明確な言葉にしろ」ということが述べられていました。

どういうことなのか？…

例えば「get」

「getPage」という関数があったとします。

ただ「get」だけではどこから取得してくるのかが全く分かりません。

• キャッシュから取得するのか？
• データベースから取得するのか？
• インターネットから取得するのか？

例えばインターネットから取得するのであれば、fetchPage()やdownloadPage()とした方が明確になります。

……

やっちまってた(^^;;

自分「get」ってめちゃくちゃ使ってますわ〜

確かに「fetch」を使ったり「download」を使った方がとても明確になりますね！

今後、何かを取得してくる関数を書く場合、思考停止で「get」を使うのはやめようと思った次第。

コメントでコードに一貫性を持たせる

4章では「コードの美しさ」について書かれれてました。

中でも62,63ページの内容はとても印象に残りました。

下記はJavaのコードです。
※リーダブルコード内で書かれているコードです。
※コードの内容は理解しなくて良いです。

public class PerformanceTester {
  public static final TcpConnectionsSimulator wifi = new TcpConnectionsSimulator(
    500, /* Kbps */
    80, /* millisecs latency */
    200, /* jitter */
    1 /* packet loss % */);

  public static final TcpConnectionsSimulator t3_fiber =
    new TcpConnectionsSimulator(
      45000, /* Kbps */
      10, /* millisecs latency */
      0, /* jitter */
      0 /* packet loss % */);

  public static final TcpConnectionsSimulator cell = new TcpConnectionsSimulator(
    100, /* Kbps */
    400, /* millisecs latency */
    250, /* jitter */
    5 /* packet loss % */);
}

横幅80文字に合わせるために、「t3_fiber」では余計な改行が入り、他の2つと見た目が変わってしまいっています。

このままだとコードに一貫性がなく、コードが読みにくい。

そのため下記のように適切な箇所に改行を入れて、一貫性のあるコードにしようとのことでした。

public class PerformanceTester {
  public static final TcpConnectionsSimulator wifi = 
    new TcpConnectionsSimulator(
      500, /* Kbps */
      80, /* millisecs latency */
      200, /* jitter */
      1 /* packet loss % */);

  public static final TcpConnectionsSimulator t3_fiber =
    new TcpConnectionsSimulator(
      45000, /* Kbps */
      10, /* millisecs latency */
      0, /* jitter */
      0 /* packet loss % */);

  public static final TcpConnectionsSimulator cell = 
    new TcpConnectionsSimulator(
      100, /* Kbps */
      400, /* millisecs latency */
      250, /* jitter */
      5 /* packet loss % */);
}

さらにコードを読みやすくするために、以下のように「コメントを入れると良いだろう」という提案がされれていました。

public class PerformanceTester {
  // TcpConnectionsSimulator(throughput, latency, jitter, packet_loss)
  //                           [Kbps]      [ms]    [ms]    [percent]

  public static final TcpConnectionsSimulator wifi = 
    new TcpConnectionsSimulator(500, 80, 200, 1);

  public static final TcpConnectionsSimulator t3_fiber =
    new TcpConnectionsSimulator(45000, 10, 0, 0);

  public static final TcpConnectionsSimulator cell = 
    new TcpConnectionsSimulator(100, 400, 250, 5);
}

先ほどまでは、引数の1つ1つにコメントが書いてあり、縦に長いコードになっていたのだが、上部にコメントで引数の説明を書くことで、よりシンプルにすることができました。

2つ目の修正はこれまでの僕には考えつかなかった発想だったので、目からウロコすぎました！（そもそも、引数1つ1つにコメントを書くことをしていなかった。）

コメントはコードの意図を書く

6章では「コメントのより良い書き方」について書かれれてました。

その中で特に印象に残ったのが「6.6 コードの意図を書く」です。

「コードの動作をそのままコメントとして残しておくのではなく」、「プログラマがコードを書いた時に、考えてたいことを書くとより良い」とのことが書かれていました。

僕が普段扱っているCSSではどんな時にに役立つかを、少し考えてみました。（本書に書かれていることがCSSに適応させるべきかというのはここでは置いておきます。）

例えば、下記のCSS

.header {
  position: fixed;
  top: 0;
  left: 0;
  right: 0;
  height: 80px;
  width: 100%;
  background-color: #ffffff;
}

.main-visual {
  margin-top: 80px;
}

headerをページの上部に固定して、headerの下のコンテンツ（ここでは「main-visual」クラスに被らないように「margin-top」をheaderの高さ分（80px）設定しているCSSになります。

ある程度CSSに精通している人、Web制作やフロントエンド開発を行っている人であれば、これをみた時になんの80pxかはすぐにわかるかと思います。

けれども、コードはどんな人に見られるかはわかりません。（「短いコードよりも理解しやすいコードにする」で書いたことに通じますね！）

ということで、いきなり現れている「margin-top: 80px;」にコメントを書いていこうと思います！

「コードの動作をそのまま書く」というと下記な感じだろうか…

.header {
  position: fixed;
  top: 0;
  left: 0;
  right: 0;
  height: 80px;
  width: 100%;
  background-color: #ffffff;
}

.main-visual {
  // margin-topに80pxを設定する
  margin-top: 80px;
}

全くもって意味のないコメントになってしまいました。（そんなことはわかってるっての^^;）

では、「コードを書いていたときに考えていたこと」をコメントとして書いておこう。（CSSはコードじゃないという話は争いが起きるので、ここでは一旦置いておきます。）

.header {
  position: fixed;
  top: 0;
  left: 0;
  right: 0;
  height: 80px;
  width: 100%;
  background-color: #ffffff;
}

.main-visual {
  // headerに被らないようにheaderの高さ分（80px）を設定
  margin-top: 80px;
}

これなら一瞬でわかる気がします！

そして、上記はいい感じのコメントな気がします！( ^ω^ )

どんなライブラリがあか日頃から見ておく

13章では「できるだけコードを書かないようにしよう」的なことが書かれれてました。

その中で特に印象に残った「13.4 身近なライブラリに親しむ」では下記のように書かれていました。

プログラマというのは、既存のライブラリで問題を解決できることを知らないことが多い。あるいは、ライブラリで可能なことを忘れていることが多い。

（中略）

ライブラリを全部覚えろと言っているわけじゃない。どんなことができそうかを感じ取るだけでいい。そうすれば、新しいコードを書いているときに、「ちょっと待てよ。これは、APIで見たような……」と思い出すことができる。

（後略）

（P172)

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

プログラマーって、とにかくいい感じのコードをたくさん書いて、いい感じのシステムを作れば自分は満足かもしれないが、お客さんはそんなことどうでもよくて、とにかく速く品質の良いシステムを作って欲しいと思っている（はず）。

ライブラリを使って同じシステムを作れるのならば、ほとんどの場合ライブラリを使った方が速く作れるし、テストも少なくできる！

先人の発明品をうまく利用するためにも、今後は時間をとってライブラリ探索をしようと思った次第です。

最後に

リーダブルコードに書かれていることは全て大事なので何度も読み返して、より良いコードを書いて、品質の高いシステムを作っていこうと思います！( ^ω^ )

（転職活動がんばろ！！）

ソフトウェアエンジニアを目指している方やまだまだ経験が浅い方は、ぜひとも読んでみてください！d(￣ ￣)