こんにちは、ニタです。

最近、オライリーの『リーダブルコード』という本を読みました。
その名の通り、読みやすいコードを書くためのノウハウが書かれた、大変ためになる内容でした。

どれだけ短期間でプログラムが出来たとしても、後で他の人が修正を加える事になった時、どこで何の機能をどのように書いているのか、全く理解できなければ、メンテナンス性の低いコードになってしまいます。
最初にプログラムを書いた人が、ずっと保守していかなければならないのでしょうか。
その人が設計内容を忘れてしまったら、どう保守していけばいいのでしょう。

様々な開発言語や、日々新しく出てくるシステムに触れてみるのも大事ですが、プログラムを書くためには、この本に書かれてあるような、もっと基礎的なことが大事だと思います。
これから数回に分けて、この本について感じたこと、大事だと思ったことを書いていきたいと思います。
よろしくお願い致します。

理解しやすいコードとは

僕がプログラマという肩書を戴き、プログラミングの仕事をもらうようになってから、自分で書いたものはともかく、様々なフレームワーク、他のプログラマの方々のコード…いろんなコードを目にしてきました。
共通して分かっていることは、「読みやすいコードは分かりやすい」ということです。
まあ、当然なことなんですけどね…。 そう、コードは理解しやすい内容じゃないといけません。
じゃあ「理解しやすい」って何でしょうか。

コードの意味が分かるということではないでしょうか。
他の人（プロジェクトに参加していない同僚や新しく参加する人）や未来の自分が、そのコードを読んで、短時間で変更を加える事が出来たり、バグを見つけることができることが「理解できる」ということではないでしょうか。
自分が書いたコードの内容って、時間が経つと忘れたりしますしね…。

「簡潔」と「安心」どちらが大事なのでしょう

また、簡潔なコードは理解しやすいと感じる場合もあるでしょう。コード数、行数が少なければその分コードを読む時間は短縮されますし。
では、この場合はどうでしょうか。

return ($foo > 0) ? $hoge * (1 * $var) : $hoge / (1 * $var);

ワンライナーで書かれていて、スマートって感じです。
これをこう書くと、どう感じるでしょうか。

if($foo > 0){
return $hoge * (1 * $var);
} else {
return $hoge / (1 * $var);
}

前者のほうが簡潔なコードですが、読んだときパッと理解できたのは後者のほうではないでしょうか。
後者の方が読んでいて分かりやすく安心します。
簡潔なコードも大事ですが、読んだときの「安心さ」も、分かりやすいコードとして大事なのではないでしょうか。

そのコード、後で読んで理解できますか？

ところで、自分が書いたコードを「理解しやすいコード」と思って書いていますか？
例えそう思っていたとしても、それは自分が仕様を理解し、設計しているからだけではないでしょうか。

前述しましたが、そのプロジェクトに関係のない同僚、もしくはそのプロジェクトに新しく入った人が、そのコードを読んで理解できる内容かどうかが大事だと思うのです。

新しくコードを書くとき、修正するとき、すぐに手を動かそうとせず、
「これから書くコードは理解しやすいコードだろうか？」と一歩引いてみることも大事だと思います。

まとめ

以上のことから、理解しやすいコードを書くためのポイントは、このようなことではないでしょうか。

• コードは（未来の自分も含む）他人が、最短時間で理解できるように書かなければならない。
• コードは短くした方がいい。でも「理解するまでにかかる時間」を短くする方が優先。
• コードを書くとき、すぐにコードの修正に入らず、「このコードは理解しやすいだろうか？」と一歩引いて自問自答し、考えることから始める。

次回は、変数名、関数名などの名前について触れてみたいと思います。
それでは、また。