BOOK Preview Code Complete 第2版　上・下 ― 完全なプログラミングを目指して ― 第34章 ソフトウェア職人気質とは マイクロソフトプレスの書籍紹介ページ 書籍情報のページ 2005/05/24

Page1 Page2 Page3 Page4

34.3 人間が1番、コンピュータは2番

あなたのプログラム ［名詞］これみよがしな技巧やとんちんかんなコメントが散乱した､論証不足の出口のない迷路。「私のプログラム」と比較せよ。 私のプログラム ［名詞］アルゴリズムを正確に記述した逸品。コンパクトで効率的なコーディングである一方で、後世の人々が判読できるように完全なコメントが付いているという、絶妙のバランスを持つ。「あなたのプログラム」と比較せよ。 ─ Stan Kelly-Bootle

　本書のもう1つのテーマは、コードの読みやすさの重要性である。他の人と意志の疎通を図りたいと思うことが、読めばわかるコードという聖杯を探し求めるきっかけとなる。

コンピュータは、あなたのコードが読みやすいかどうかなど気にかけない。コンピュータにとっては、高級言語で書かれたステートメントよりも、バイナリのマシン命令を読む方がたやすい。読みやすいコードを書くのは、他の人があなたのコードを読む助けになるからだ。読みやすさは、プログラムの次の面でプラスに働く。

• 理解しやすさ
• レビューのしやすさ
• エラーの割合
• デバッグ
• 変更のしやすさ
• 開発時間（上記のすべての結果）
• 外部品質（上記のすべての結果）

　読みやすいコードは、少なくとも短期的に見て、ややこしいコードを書くよりも時間はかからない。自分が書いたものが簡単に読めるとすれば、そのコードが動くことに確信を持ちやすい。それだけでも、読みやすいコードを書く十分な理由になる。さらに、コードはレビューの段階でも読まれる。あなたや他のだれかがエラーを修正するときにも読まれる。コードを変更するときにも読まれる。だれかがコードの一部を似たようなプログラムに使用するときにも読まれる。

プログラミングの初期の時代、プログラムはプログラマの私有財産と見なされていた。プログラマたちは、だれかのラブレターを取り上げて読んだりしないように、仲間のプログラムを頼まれもしないのに読んだりすることなど考えてもいなかった。プログラムとは基本的にそういうものだった。プログラマからハードウェアへのラブレターであり、恋人どうしにしかわからない秘密の内容に満ちていた。こうしてプログラムは、宇宙に自分たちしか存在しないかのような、非現実的な至福の時を過ごしている恋人どうしが交わす短縮言葉やペットの名前で、ごてごてと飾られるようになった。そのようなプログラムをパートナー以外の者が理解できるわけがない。 ─ Michael Marcotty

　コードを読みやすくすることは、開発プロセスのオプション部分ではない。そして、読むときの便宜ではなく書くときの便宜を図るのは不経済である。悪いコードを読もうとして何度も読み返すのではなく、良いコードを書くことに努力を向けるべきである。それは一度行えば済む。

　「自分のためのコードを書いているだけならどうなのか。なぜ読みやすくする必要があるのか」―― それは、今から1、2週間後にあなたは別のプログラムを書くことになり、「なんだ、このクラスは先週書いたやつじゃないか。テストとデバッグが済んでいるコードを持ってくれば手間が省ける」と考えるからだ。コードが読みやすく書かれていない？ 健闘を祈る。

　たった1人のプロジェクトだからといって読みにくいコードを書くことは、危険な前例を作ることである。母親の口癖は「そんな顔をして、そういう顔になったらどうするの」で、父親の口癖は「練習どおりに試合をすればいい」であった。習慣はあなたのすることなすことすべてに影響する。習慣を意のままに操ることはできないので、習慣として身につけたいことをするようにしよう。プロのプログラマは読みやすいコードを書く。それだけである。

　コードが絶対に自分だけのものであるかどうかには論争の余地があることもわきまえておこう。Douglas Comerは、プライベートなプログラムとパブリックなプログラムをうまく区別する方法を思い付いた（Comer 1981）。「プライベートなプログラム」とは、プログラマが個人的に使用するプログラムである。それらを他人が使用することはないし、他人が変更することもない。他人はそのプログラムが存在することすら知らない。プライベートなプログラムは、通常はたいしたものではなく、それらはまれに見る例外である。それに対して「パブリックなプログラム」とは、作成者以外の人が使用したり修正したりするプログラムである。

　パブリックなプログラムとプライベートなプログラムのための標準は異なる可能性がある。プライベートなプログラムはずさんに書かれている可能性があり、作成者以外のだれにも関係のない制限でいっぱいである。パブリックなプログラムはもっと慎重に書かれていなければならない。制限は文書化されていなければならないし、信頼性がなければならないし、変更できるものでなければならない。プライベートなプログラムは、しばしばパブリックなプログラムになることがあるので、その点に注意しよう。プログラムを一般に公開する前に、パブリックなプログラムとして書き換える必要がある。プライベートなプログラムをパブリックなものにする作業の1つは、読みやすくすることである。

　自分のコードを読むのは自分だけだと思っていても、現実には、他のだれかがあなたのコードを変更する可能性は十分にある。ある調査で、平均的なプログラムが書き直されるまでに、10世代の保守プログラマがそれに従事することが判明している（Thomas 1984）。保守プログラマは、保守しなければならないコードを理解することに作業時間の50〜60%を費やすので、コードを文書化する時間を割いてくれたことに感謝するだろう（Parikh and Zvegintzov 1983）。

　本書のここまでの章では、クラス、ルーチン、変数に良い名前を付ける、フォーマットについてよく考える、ルーチンを小さく保つ、複雑な論理評価をブール関数に隠ぺいする、中間結果を変数に代入して複雑な計算を明確にするなど、読みやすさを実現するのに役立つテクニックについて検討してきた。これらのテクニックを個々に適用するだけでは、読みやすいプログラムと読みにくいプログラムの違いを生み出すことはできないが、読みやすさを改善するための小さな作業を積み重ねることが大きな違いを生むだろう。

　他のだれかがコードを見ることはないのでコードを読みやすくする必要はないと考えているなら、原因と結果を混同しないようにくれぐれも注意しよう。

34.4 言語の中へのプログラミング

　プログラミングについて考察するときに、言語が自動的にサポートする概念に縛られてはならない。優秀なプログラマは、自分が何をしたいのかを考えてから、手元のプログラミングツールを使って目的を達成する方法を判断する。

　クラスのメンバルーチンがクラスの抽象性と矛盾する場合、便利だからといって、一貫性のないものを使用してもいいものだろうか。クラスのインターフェイスが表す抽象性をできるだけ維持するようにコードを書くべきだろう。使用している言語がサポートしているからといって、グローバルデータやgoto文を使用する必要はない。そうした有害なプログラミング機能は使用しないことに決め、代わりにプログラミング規約で言語の弱点を補うべきである。最も手っ取り早い方法をとるプログラミングは、結果的に、言語の中へのプログラミングではなく、言語の中でのプログラミングになる。「フレディーが橋から飛び降りたら、君も橋から飛び降りるのか」ということを、プログラマに置き換えてみればよい。技術的な目標について考えてから、言語の中へのプログラミングによってその目標を達成するための最も良い方法を判断しよう。

　使用している言語がアサーションをサポートしない場合は、独自のassertルーチンを書けばよい。組み込みのassertルーチンとまったく同じように機能するとは限らないが、独自のルーチンを書けばassertルーチンのほとんどの利点が得られる。使用している言語が列挙型や名前付き定数をサポートしないなら、それでもかまわない。列挙型や名前付き定数は、明確な命名規則に従ってグローバル変数を規則正しく使用すればエミュレートできる。

　極端な例を挙げれば、特に新しい技術環境では初歩的なツールしか揃っていないために、プログラミングの手法を当初の目的から大幅に変更せざるを得ない場合がある。そのような場合は、言語の中へのプログラミングを求める気持ちと、当初の手法を貫くとあまりにも面倒であるという不測の事態との折り合いを付ける必要があるだろう。だがそのような場合には、そうした環境の最も有害な機能を避けるようなプログラミング規約を設けると、さらに効果的である。より一般的な状況では、あなたがしたいこととツールがサポートすることに格差があるため、環境にほんの少し譲歩する必要があるだろう。

34.5 集中力を助ける規約

　一連の規約は、複雑さに対処するための知的な道具の1つである。ここまでの章では、特定の規約を取り上げた。ここでは、さまざまな例を交えて、規約の利点を挙げていこう。

参照 第31章の「31.1.4 良いレイアウトの価値」および「31.1.6 良いレイアウトの目標」では、プログラムのレイアウトに規約を適用した場合の価値を分析している。

　プログラミングには、ある程度自由に決められる部分がかなりある。ループのインデントのスペースはいくつにするか。コメントのフォーマットはどうするか。クラスのルーチンの順序はどうするか。これらの質問のほとんどに、正しい答えがいくつかある。これらの質問にどう答えるかよりも、毎回答えが一貫していることの方が重要である。規約があれば、プログラマが同じ質問に答える必要はなくなる。つまり、同じ決断を何度も繰り返さずに済む。多くのプログラマが関与するプロジェクトでは、規約を用いることで、プログラマごとに決断が異なるために混乱が生じる、ということがなくなる。

　規約は、重要な情報を簡潔に伝える。命名規則では、たった1文字によって、ローカル変数、クラス変数、グローバル変数を区別することができる。大文字の使用によって、型、名前付き定数、変数を区別することができる。インデントの規約は、プログラムの論理構造を簡潔に示すことができる。配置の規約は、ステートメントが関連していることを簡潔に示すことができる。

　規約は、既知の危険を未然に防ぐ。規約を設ければ、危険なプラクティスを排除して、それらを必要な場合だけに限定することや、既知の障害を補正することができる。たとえば、グローバル変数を禁止したり、1行に複数のステートメントをまとめることを禁止したりすることで、危険なプラクティスを排除する。また、複雑な式をかっこで囲むことを義務付けたり、ポインタを削除したらすぐにNULLに設定してダングリングポインタを防ぐことを義務付けたりすれば、危険なプラクティスを補正することができる。

　規約は、下位レベルのタスクを予測しやすくする。メモリ要求、エラー処理、入出力、クラスインターフェイスを規則的に処理するようにすれば、コードの構造に意味を持たせることができる。他のプログラマはその規約さえ知っていれば、コードを理解できるようになる。前述のように、グローバルデータを排除する最大の利点の1つは、さまざまなクラスやサブシステムどうしがやり取りする可能性をなくすことである。読み手は、ローカルデータとクラスデータがどのようなものかはだいたい見当がつくが、グローバルデータが変更されたら4つのサブシステムを超えた先にあるコードが動かなくなることを見抜くのは難しい。グローバルデータは、読み手の確信のなさを助長する。良い規約を設ければ、あなたもあなたのコードの読み手も、もう少し見通しがよくなる。理解しなければならない情報が少なくなるので、必然的に、プログラムへの理解が深まる。

　規約は、言語の弱点を補うことができる。名前付き定数をサポートしない言語（Python、Perl、UNIXシェルスクリプトなど）では、読み書きされる変数と読み取り専用の定数とを規約で区別することができる。グローバルデータやポインタを規則正しく使用するための規約は、言語の弱点を規約で補うもう1つの例である。

　大規模なプロジェクトに従事するプログラマは、規約の虜になることがある。標準やガイドラインを次々に設けて、それらを覚えることにかかりきりになる。逆に、小規模なプロジェクトに従事するプログラマは、規約を「遠巻きに見る」傾向にあり、理知的に考えられた規約の利点を完全に理解しようとしない。規約の本当の価値を理解し、それらをうまく利用しよう。規約を使って、構造が必要な部分に構造を提供しよう。

INDEX
	Code Complete 第2版　上・下
	第34章 ソフトウェア職人気質とは
	1．34.1 複雑さの克服
	2．34.3 人間が1番、コンピュータは2番
	3．34.6 問題領域に立ったプログラム
	4．34.8 反復、その繰り返し

　

「BOOK Preview」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）