読者です 読者をやめる 読者になる 読者になる

MyEnigma

とあるエンジニアのブログです。#Robotics #Programing #C++ #Python #MATLAB #Vim #Mathematics #Book #Movie #Traveling #Mac #iPhone

13. コードレイアウトの重要性 Steve Freeman:『プログラマが知るべき97のこと』

以下の記事は,オライリージャパン社から出版された

プログラマが知るべき97のこと』

の中から1つのエッセイを選び,

そのエッセイを,クリエイティブコモンズ3.0の条件の元で転載したものです.

Creative Commons ― 表示 3.0 アメリカ合衆国 ― CC BY 3.0

本書の内容は,オープンソースモデルに従い,

ほぼ無制限で利用が可能です.

クリエイティブ・コモンズ表示3.0の条件下で,

自由に使用することができるのです.

つまり,どのエッセイも,

著者の名前を明記すれば,自由に転載,改変が可能であるということです.

ーー"はじめに"から抜粋 pXII


もし,他のエッセイを読みたい場合には,

記事末のリンクを辿るか,

以下のリンク先のTwitterアカウントのつぶやきからお探し下さい.

Twitter Account: 97 Things Bot



また,元の英文によるエッセイを読みたい方は,

こちらを参照して下さい.

Contributions Appearing in the Book - Programmer 97-things


13. コードレイアウトの重要性 スティーブ・フリーマン (Steve Freeman):『プログラマが知るべき97のこと』

もう何年も前のことですが,

私は以前,COBOLを使ったシステム開発

関わっていたことがあります.

そのシステムでは,十分な理由が無い限り,

インデントを変更してはならないという規則になっていました.

誰かが余分なインデントを入れてしまったために,

システムに異常が起きたということが以前あったためです.

この規則は,

適切なコードレイアウトにしないと

コードの意味が誤解されやすい場合にも,

例外なく守られなければならないことになっていました.

その結果,実際に誤解を招くことがよくあったので,

私たちは常に不安に苛まれ,慎重にコードを読んでいました.

この規則はプログラマにとって大きな足かせになっていたし,

それによるコストも大変なものだっただろうと思います.



プログラマは仕事の時間を,

実際にコードをタイプすることよりも,

コードを探すことと読むことに費やしている,

そんな調査結果もあるようです.

修正すべき箇所はないか?

あるとすればどこか?

それを確認する時間の方が長いということです.

そこで私は何とか

この「探したり読んだり」の効率化を図りたいと考えました.

私の考えた効率化策は次の3つです.


目立たない部分を作る

人間は視覚的なパターンマッチングはとても得意です.

(サバンナでライオンの姿を見つけなくてはいけなかった

過去の名残かもしれません)

そこで私は,

コードの中でも,ドメインに直接関係ない部分

商用プログラミング言語のコードでは必ず発生する,

いわゆる「偶発的複雑性」の部分を,

他の部分より目立たせない様にする方法を考えました.

そうゆう部分の書き方のパターンを皆同じにすることにしたのです.

同じように書かれている部分が続くと,

それはまるで「背景」のように見えます.

見た目が似ているコードは動きも似ているという

原則が徹底していれば,

違いをすぐに見つけることができます.

人間の視覚は,他と違っている部分を

すぐに見つけられるようにできているからです.

私は,1つのクラス,

1つのコンパイル単位の中での構成要素,

つまり,定数,フィールド,パブリックメソッド,プライベートメソッドなどを

どのようにレイアウトするかを定めた規則を設け,

それを常に守るようにしています.


レイアウトに語らせる.

コードの構成する各部分には,

それがどんなもので,

どんな役割を持っているかが,

すぐにわかるような名前を付けるべき,

私たちはそう教わって来ました.

でも大事なのは名前だけではありません.

見てすぐに分かるコードを書くためには,

レイアウトも重要です.

そのためにまずすべきことは,

フォーマッタ*1を使用することについて,

開発チームのメンバの同意を得て,

各構成要素のフォーマットのルールを決め,

それが自動的に守られるようにすることです.

そして細かい部分はコーディング中に各自が手で調整することにします.

まれに意見の不一致が見られることもありますが,

各自の意見の不一致は,

すぐに「手で調整」方式に収束するはずです.

フォーマッタは人間の意図を汲んでくれません.

(以前,私は実際にフォーマッタを書いたことがありますが,

本当にそうです)

重要なことは,

コードの(要素としての)改行,

及び(インデント等による)グルーピングは,

言語の構文を満たすだけでなく,

何らかの意図を表している必要があるということです.

(私は自動フォーマッタに頼りすぎるきらいがありましたが,

Kevin McGuireがその呪縛から解き放ってくれました)


コンパクトにまとめる

画面に一度に表示できるものが多くなれば,

スクロール量やファイルの切り替えが少なくて済みます.

つまり「コンテキストが分断される」ことが減るわけです.

頭の中に保持して置かなければならない情報も減ります.

長いコメントを入れたり,

ホワイトスペース*2を多く入れたりすることは,

名前に8文字の制限があった時代,

ラインプリンタの時代には意味がありました.

ですが,今やシンタックスハイライトやクロスリンクなどの機能が使えるIDEの時代です.

つまりディスプレイの大きさの制約の方が大きいのです.

できるだけ多くの要素を一度に見渡せた方が,

コードは理解しやすくなります.

別の言い方をするなら,

レイアウトはコードの理解を助けるために行うべきで,

コードの理解を助ける異常は求めてはいないということです.



以前,プログラムにあまり詳しくない友人から

「コンピュータのプログラムは詩みたいに見える」

と言われたことがあります.

本当に素晴らしいコードを見た時は,

私も同じように感じたことがありました.

書かれた文字がすべて何らかの目的を持っていて,

しかも見るだけでその目的がどういうものなのかすぐにわかる,

そんなコードでした.

ただ,プログラムを書く作業には詩を書くような

ロマンティックなイメージはないので,

それが残念ですね.



■著者データ

[スティーブ・フリーマン (Steve Freeman)]

フリーのコンサルタントであり,

アジャイルソフトウェア開発を専門としている.

世界各国のソフトウェア開発チームに加わり,

リーダー,コーチ,トレーナーなどの仕事をしてきた.

『Growing Object-Oriented Software, Guided by Tests』

の共著者でもあり,

2006 Agile Alliance の"Gordon Pask Award"の受賞者の一人でもある.

jMock, Hamcrestプロジェクトのコミッタ,NMockのオーサの一人.

eXtreme Tuesday Clubの創立メンバでもあり,

London XpDay初回のチェアパーソンでもある.

多数の国際カンファレンスに,運営者やプレゼンターとして加わっている.

ケンブリッジ大学で博士号を取得し,統計学や音楽の学位も取得している.

最近特に力をいれているのは,より良いコードを書くことと,

組織の複雑性について研究すること.

Webサイトも参照のこと.

Steve Freeman



*1:文書の整形を行うアプリケーションフォーマッタとは【formatter】 - 意味/解説/説明/定義 : IT用語辞典

*2:ホワイトスペースとは、プログラム言語やHTMLのコードにおいて、ソースコードには空白や改行として表現されるが、最終的にブラウザなどで表示させた際には画面に反映されないような文字のことである。ホワイトスペースとは (white space): - IT用語辞典バイナリ