"プログラミング"というものを初めて学んだのは大学一年の授業で、C言語だったのだけど、それ以来そういった授業という場でプログラミング言語を学ぶ機会はなかった。
授業によってはJavaを使ったり、卒業研究ではPHPやActionScriptを使ったりはしたけれど、誰かに教わるというよりは自分で調べてなんとなく"動くもの"を書いてた。ソースコードの美しさは度外視して。
いや、よくよく考えてみれば、初めてプログラミングをしたのはもっともっと前だ。正確にはわからないけれど、小学五年くらいからホームページ制作に挑戦し始めて、最初はビジュアルエディタだったのが、いつの間にかテキストエディタになってた。
それはともかくソースコードを書くということ
まず前提として、"動くソースコード"でなければならないわけだけど、それ自体なかなか難しい（と思ってる）。自分の意図した仕事を、自分の意図した通りに行うのがいかに難しいかは実際の仕事でも感じることだし、それはプログラミング上でも同意。
ただ、プログラミングは一度書いたら終わり、ではなく（実際の仕事も繰り返すことは多いが）、何度もリファクタリングしたり、何度もリサイクルしたりが多い。その際、自分ではない他の誰かがそれをすることだって多い。
この本はそんな状況下において、如何に読みやすいソースコードを書くかについて、その為のテクニックが多岐に渡る言語のサンプルと共に紹介されている。
- 表面上の改善
- ループとロジックの単純化
- コードの採光性
- 選抜テーマ
このような部に分かれた本書では、とにかく理解しやすいコードの書き方を徹底的に比較・解説。変数の名前の付け方からコメントの書き方、コードブロックの分割や並び方などなど、すべてを適用したらまるっきり異なるコードになっちゃうんじゃないかってほど笑
短いコードを書く、または書かない
理解しやすいソースコードを書く、ということへの最大の貢献はソースコードを書かないということ。これでは前提が違うじゃないか、という話かと言えば、そうではない。一般的には、短いソースコードは美しいし、読み解く時間も短くなる。（例外は大いにあるけど）
ならば、ソースコードを書かなければ読み解く時間は必要ない。至極納得できる発想ではあるが、それではそもそも開発というものが成立しない。と思ったらそういうことではない。既に存在するコードを使う、という。
用意されているAPIはもちろん、各種ライブラリやフレームワークなど、世の中で確立されたコードだけでなく、過去に自分で書いたソースも再利用できるならば積極的にしていく。実績のあるコードならバグの心配も少ないし、何より書かなくていいから軽量。
テストコードを書く
実装した機能のテストを行う為のテストコードを書くことは、開発段階においてはよくあること（あまり経験はないが...）だけど、先にテストコードを書き、その後で実装するTDD（テスト駆動開発）という開発手法にも軽く言及されている。
その手法を手放しで賞賛するって話じゃないけど、どうやらテストを意識しながらコーディングするということは重要らしい。テストをし易いように設計をするようになる、と。
そして、テストコード自体もリーダブルなコードである必要があり、もし、そうでなかったら他の誰かがテストコードを追加しようにもできず、テストの漏れが出たり、ひいてはテストコードの変更を回避するため、機能の改修すら回避してしまう。
手元に置いておきたい一冊
とある言語がversion upしたり、仕様が変わったりすることはあっても、あらゆる言語に適用できるリーダブルなコードの書き方が一夜にして変わるなんてことはまず有り得ない。（実際には一夜で大幅に仕様変更される言語はないが。）
そういった意味で、常に自分のソースコードを進化させていく為には書き続けることが大切。それも読みやすさを意識して書き続けることが大切。この本が不要になった時、それが誰しもにとってリーダブルなコードの書き手になったということ。
[amazonjs asin="4873115655" locale="JP" title="リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)"]
