【13】コードレイアウトの重要性

　もう何年も前のことですが、私は以前、COBOL を使ったシステム開発に関わっていたことがあります。そのシステムでは、十分な理由がない限りインデントを変更してはならない、という規則になっていました。誰かが余分なインデントを入れてしまったために、システムに異常が起きたということが以前あったためです。この規則は、適切なコードレイアウトにしないとコードの意味が誤解されやすい場合にも、例外なく守らなければならないことになっていました。その結果実際に誤解を招くことがよくあったので、私達は常に不安に苛まれ、慎重にコードを読んでいました。この規則はプログラマにとって大きな足かせになっていたし、それによるコストも大変なものだったろうと思います。

　プログラマは仕事の時間を、実際にコードをタイプすることよりも、コードを探すことと読むことに費やしている、そんな調査結果もあるようです——修正すべき箇所はないか、あるとすればどこか、それを確認する時間のほうが長いということです。そこで私は何とかこの「探したり読んだり」の効率化を図りたいと考えました。私の考えた効率化策は次の 3 つです。

目立たない部分を作る

人間は視覚的なパターンマッチングはとても得意です（サバンナでライオンの姿を見つけなくてはいけなかった過去の名残かもしれません）。そこで私は、コードの中でも、ドメインに直接関係のない部分——商用プログラミング言語のコードでは必ず発生する、いわゆる「偶発的複雑性」の部分——を、他の部分より目立たせないようにするという方法を考えました。そういう部分の書き方のパターンをみな同じにすることにしたのです。同じように書かれている部分が続くと、それはまるで「背景」のように見えます。見た目が似ているコードは動きも似ているという原則が徹底されていれば、違いをすぐに見つけることができます。人間の視覚は、他と違っている場所をすぐに見つけられるようにできているからです。私は、1 つのクラス、1 つのコンパイル単位の中での構成要素、つまり、定数、フィールド、パブリックメソッド、プライベートメソッドなどをどうレイアウトするかを定めた規則を設け、それを常に守るようにしています。

レイアウトに語らせる

コードを構成する各部分には、それがどんなもので、どんな役割を持っているかがすぐに分かるような名前をつけるべき、私達はそう教えられてきました。でも大事なのは名前だけではありません。見てすぐわかるコードを書くためにはレイアウトも重要です。そのためにまずすべきことは、フォーマッタを使用することについて、開発チームのメンバーの同意を得て、各構成要素のフォーマットのルールを決め、それが自動的に守られるようにすることです。そして、細かい部分はコーディング中に各自が手で調整することにします。まれに意見の不一致が見られることもありますが、各自の意見の不一致は、すぐに「手で調整」方式に収束するはずです。フォーマッタは人間の意図を汲んではくれません（以前、私は実際にフォーマッタを書いたことがありますが、本当にそうです）。重要なことは、コードの（要素としての）改行、および、（インデント等による）グルーピングは、言語の構文を満たすだけでなく、何らかの意図を表している必要があるということです（私は自動コードフォーマッタに頼りすぎるきらいがありましたが、Kevin McGuire がその呪縛から解き放ってくれました）。

コンパクトにまとめる

画面に 1 度に表示できるものが多くなれば、スクロール量やファイルの切り替えが少なくて済みます。つまり「コンテキストが分断される」ことが減るわけです。頭のなかに保持しておかねばならない情報も減ります。長いコメントを入れたり、ホワイトスペースを多く入れたりすることは、名前に 8 文字の制限があった時代、ラインプリンタの時代には意味がありました。ですが、今やシンタックスハイライトやクロスリンクなどの機能が使える IDE の時代です。つまりディスプレイの大きさの制約の方が大きいのです。できるだけ多くの要素を一度に見渡せた方が、コードは理解しやすくなります。別の言い方をするなら、レイアウトはコードの理解を助けるために行うべきで、コードの理解を助けること以上は求めてはいないということです。

　以前プログラムにあまり詳しくない友人から「コンピュータのプログラムは詩みたいに見える」と言われたことがあります。本当に素晴らしいコードを見た時は、私も同じように感じたことがありました——書かれた文字がすべて何かしらの目的を持っていて、しかも見るだけでその目的がどういうものなのかすぐにわかる、そんなコードでした。ただ、プログラムを書く作業には詩を書くようなロマンティックなイメージはないので、それが残念ですね。