リーダブルコードを(今さらながら)読んだ

会社の行き帰りの電車の中で読んだので、まだいまいち頭の中に入っていなくて復習が必要だけど。

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

Googleの人が書いたらしい。Googleのコーディングルールとかもこうなっているし、美しいコードを書くというのは、それだけ手間のかかることだし、つい油断するとその場しのぎのコードになってしまうよなー、ということで。

1. 一歩下って、自分のコードを見つめ直す。 これ、大切だって良く分かる。特に、「今動けば良いや！」的なコードはそうなり易いなって思っている。コードのdiffだけでは読みとることのできない、全体として何をしたいのか？を見つめ直すと、おのずとどのように記述すれば分かり易いのかが見えてくる。経験上ね。
2. 変数名は語る。 変数名はとても大事だと分かる。特に、Verilog-HDLなどの、時間的な概念を気にしている僕はいつもそのことは気にかける。「この変数(レジスタ)は何時、どのステージで有効になるのか？」を示すために、変数名は非常に有効な読解手法となる。逆に言えば、この変数名の定義がしっかりしていれば、もはや変数名のコメントなど、必要無いのだ。
3. 短く書くためには、どうすれば良い？ これは、自分のコーディング時間を短縮するためでもあると思う。大量に同じようなコードを書いていると(しかも長いと)、必ずミスする。昔コンパイラを開発していたとき、データ構造を探索するために大量のポインタリストを使っていたが、同じような探索でも違うデータ構造だと似たようなコードを大量に書いていた(今思えばアホだと思う...ちゃんとSTLとか、ライブラリとか使おうよ...)。同じようなコード、しかも長いコードを何度も書いていると必ずミスする。だから、ライブラリを積極的に使う。
4. ライブラリを使っていれば幸せなのか？ 3番と矛盾しているように見えるが、そうじゃなくて、ライブラリの特徴も理解しておかなければ、と思う。例えばC++のSTLだと、setとvectorは特徴の違いで、探索の時間に雲泥の差が出る。ライブラリの使い方、だけでなく、ライブラリの特徴を把握して、うまく使い熟すのが重要だと思う。

まあ、いろいろ書いたけど、まだまだ自分は未熟で、つい一週間前に書いたコードですら直したくなることが良くある。そこらへんは、日々勉強だな。 自分一人で書くだけでなく、オープンソースの世界や、社内でも優れたチームの中でコーディングをすると、いろんな勉強になることがある。 プログラミングコンテストに積極的に参加するのも良いし、そうやって他人からの刺激を受け続ければ、自分の「日頃のふとしたコードの書き方」から、少しずつ変わっていけるんじゃないかな。