「リーダブルコード」を読んで
はじめまして、ハンズラボの井上です。
ハンズラボには、おじさんがひたすらお酒を飲むブログとかがあって好評？連載中なのですが、酒飲んでるだけじゃなくて一応仕事もしてるんだぞアピールとして、技術的な話題などはこちらに掲載していきたいと思います。
１回めの記事では、正月休みに読んだ、「リーダブルコード」という本について、だらだらコメントなどを書いてみたいと思います。
まず、この本を読んで感じたのは、
プログラムは、単に、コンピュータに命令を実行させるための、命令の羅列だけではなく、開発者間のコミュニケーションの媒体としての側面もある
という点です。
もちろん、プログラムは、想定通りの仕様にそって正確に動作する必要があるのですが、その想定どおりの仕様 というのは、時と共に変化します。
また、開発者自体も、最初に作成した人から、それを運用する方、緊急の不具合対応する方など、どんどん変遷していきます。
が、その中心にあるのは、常に動いているソースコードです。
開発者は、ソースコードを通していろいろな人（仕様を決めた人や、設計した人、実際にコーディングした人）の意図を汲み取りながらメンテナンスし続けなければなりません。
子供の頃、少年野球でキャッチボールの練習の際に、
「相手のことを考えて、相手が取りやすい位置に投げてあげるんだ」
と口を酸っぱくして言われましたが、プログラミングも一緒で、常にそのコードには受け取り手がいることを意識し、受け取りやすいように書いてあげないといけないと思いました。
俺さえわかればいい、動きゃなんでもいい というコードをメンテナンスするのは辛いですからね。
で、具体的にどうすればいいの？
という問に対する答えが、この本には、具体例を交えて簡潔に書かれていて、とても良かったです。
- コメントはどのような時に、どのように書くのが良いか
- 関数名、変数名などの名前の付け方について
- どうやってコードを簡潔に保つか（巨大化を避けるか）
などなど。
薄々気づいていて、なんとなく実践していたようなことも、改めて明文化されたものを読むと、やっぱりね、と思ったり、こんなこと知らなかったという点もちらほらあり、発見でした。
いくつか例を上げます。
コメントは正確で簡潔に、コードの意図を書く
例えば、下記のようなコード。
// list を逆順にイテレートする
for (list::reverse_iterator it = products.rbegin(); ... ) {
}
// 値段の高い順に表示する
for (list::reverse_iterator it = products.rbegin(); ... ) {
}
この２つでは、下のコードの方がより、最終的に何がしたいか、が分かってよいです。
上のコードは、単に実行している内容を日本語に翻訳しただけの内容で、”見りゃわかる” 内容です。
たまに見かける、
# ライブラリの読み込み
require 'hoge'
require 'foo'
みたいなコメントはあんまり意味がないです。ライブラリを読み込んでいるのは、見りゃわかるからです。
そういった、ただ実装内容をただ書いただけのものは意味がなく、
なんでこうする必要があったのか？
という部分によりコメントを充実させるべきです。
そういった、実装に至った背景というものがコードに残っていないと、イタコを呼んでその当時の開発者の言霊を呼び出してもらう必要が出てしまって、コストがかかります。（遠くの恐山より適切なコメント）
行数を短くするよりも、他の人が理解するのにかかる時間を短くする
例えば、こんなコード。
if (no_check_flag != 1) {
# チェックするコードが続く
}
最近見たコードですが、読んだ瞬間、ファッ？？となりました。
このフラグの定義を見ると、1: チェックしない 2: チェックする
のようでした。
(1) フラグ は 0/1 か、true/false であって欲しい。
1/2だと、どっちがどっちの意味か分かりずらい。
(2) フラグなどは肯定形にするべき。
否定の否定になると、脳が一瞬混乱し、バグを誘発します。
否定の否定は良くなくない？よくねーよ。
同じコードでも、下記の場合には特に驚きはないと思います。
if (check_flag == true) {
# チェックするコードが続く
}
このフラグの例は、コードだけではなく、DB設計の時にも言えますね。
否定形のフラグは持たないようにする。
まぁ分かるんですけどね。
運用者「こういう種類の商品は○○させたくないです！設定できるようにしてください！」
開発者「分かりました。 ○○できないフラグ作りました！」
って感じでしょうか。
言われたものをそのまま作るのではなく、一旦システムとしてどうなっていた方が良いか、立ち止まって考える余裕が欲しいところです。
まだまだ、他にも紹介したい内容はありますが、もし興味を持ったら、手にとって読んでいただきたいと思います。
この本の何が素晴らしいって、薄くて簡単に読める点です。
読み手の事を考えて簡潔に とか書いているくせにCODE COMPLETEのようにでかくて分厚かったら笑えますが、そんなことありませんのでご安心を！
ではでは。
