前回の記事に明示的に書いてはいませんが、2019年の目標の1つとして「毎月1冊以上の技術書籍を読み、ブログにその内容をまとめる」ということをやっていく予定です。
(こういうのってネタバレ的な要素があってどこまで書いていいものかよく分かっていないので、あかん部分があればコメントいただけると嬉しいです)

書籍の選定理由

2019年最初の書籍として、プログラマー界隈では名著と呼ばれる「リーダブルコード」を選びました。五線譜が表紙にありますがアカペラ関連ではなくプログラミングに関する書籍です。笑
概要は以下のAmazonの商品ページにも記載されているので、ご存知ない方はそちらをご参照ください。
選定理由としては、最初から長すぎるものだとすぐ挫折しそうっていうのと笑(この書籍は231ページと、技術書籍の中ではかなり短い方だと思います)、コードを書いていて「変数・関数の命名とか、行いたい処理をシンプルに書くのってめっちゃ難しい」と感じることが昨年多く、その解決の糸口が見つかればいいなと思ったからです。

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

Amazon

流し読み程度に1回読んだことはありましたが、明確な意思を持って読むと理解の度合いが違うなと早速感じています。またこのように文章としてアウトプットしていくことで、自分の言葉を交えて整理することも重要だと思っています。

ではここから、書籍の内容に入っていきます。肩慣らしの意味も込めて、今回の記事では1章の内容だけを取り上げます。1章は「理解しやすいコード」というタイトルです。

"リーダブル"なコードとは

恥ずかしながら、1回目に読んだときは"リーダブル(Readable)"がどういう意味かちゃんと理解せずに読み進めてしまっていたのですが、今回改めて読み直すと「リーダブル＝理解しやすい」とタイトルにある程度答えがありました。笑
(前回は本当にただただ流していただけだったんだなと反省しています)

1章では、何度か言葉を変えてリーダブルなコードの何たるかが書かれていました。いくつか本文を引用させていただくと、

コードは他の人が最短時間で理解できるように書かなければならない。

「他の人」というのは、自分のコードに見覚えのない6か月後の「君自身」かもしれない。

コードは短くした方がいい。だけど、「理解するまでにかかる時間」を短くする方が大切だ。

このあたりから、"リーダブル"なコードとは記述されたプログラムの内容を自分自身を含めた全ての人が最短時間で理解できるように書かれたコードのことなんだなと解釈しました。

1章の内容はここまでです。ページ数はたったの4ページですが、ここにこの書籍の大事な要素が詰まっていた気がします。
次章以降ではコードをリーダブルにしていく具体的な方法について、センテンスレベルから関数レベルへと広がる形で書かれています。

所感

僕自身を含め多くのプログラマーは新しく知ったことがあるとついつい使いたくなるし、使っている間は楽しい時間を過ごせると思います。それはそれで大切な作業ではあるのですが、それよりも理解しやすさを追求する方が大切だと改めて気付かされました。
よくよく考えると、こういうブログとか論文発表資料は明確に「読む相手・見る相手」を意識して書いていたのに、プログラミングになると途端に自分のことだけを考えていたような気がします。

あと、少々細かい話にはなりますが、リーダブルなコードについて考えるにあたって「言語特有の記法」の捉え方が難しいと感じました。いわゆる専門用語に近いものと思います。
僕自身はAndroid/iOSアプリの開発を主に行なっているのでKotlinとSwiftを扱うことが多いのですが、例えばKotlinのlet、applyなどのスコープ関数や Swiftのguard let、if letなどのOptional Bindingがリーダブルかどうかは、関わるメンバーのスキルにも依存すると思います。
また、最近では割とスタンダードになりつつあるRxなどについても、その便利さは理解できますし実際に使ってもいますが、1つのパラダイムを理解するコストやデバッグのし辛さ(単純に使いこなせていないだけかもしれませんが、個人的にはデバッグし辛いと思っています)などを考えると、これがリーダブルと言えるのかいささか疑問ではあります。
このあたりをプログラマーの方々がどうバランス取って解決していってるのかは気になりどころです。書籍や技術記事、各言語のコーディング規約などを読みながら自分なりの正解を見つけていきたいです。

ところで、僕のブログはちゃんと"リーダブル"なものになっているのかな…笑