はじめに
こんにちは、Go界のシャールト・コプリーです。気がついたら最後のエントリから3ヶ月も経ってました。
Goを始めると「なんでこういう書き方になってるんだろう」とか、「そもそもなんでこういう仕様になってるんだろう」とか思うことがちらほらあると思います。これは大いにGoの作者の一人であるRob Pike氏の思想に依るところがあるのが見受けられます。彼のプログラムに対する考え方が25年前に公開され「Pike Style」として知られていますが、いまもその考え方は大きくは変わっていないと思われます。せっかくなので翻訳しました。本文はC言語に関する文章ですがその本質は言語に依らないものだと思います。
（追記）25年前なのでコンパイラの動作に依存する部分（includeに関する記述）などは古い部分もありますが、プログラミングスタイルに関する部分は現代にも通じるところがあると思います。
（追記2）幾つか誤訳をご指摘いただけたので修正いたしました。コメントに感謝しています。
（追記3）僕の役はひどいのでこちらを読みましょう。
誤訳箇所の一覧です。
C言語でプログラミングする際の覚書
Rob Pike 1989年2月21日
Copyright (C) 2003, Lucent Technologies Inc. and others. All Rights Reserved.
まえがき
KernighanとPlaugerの “The Elements of Programming Style” （「プログラム書法」木村泉訳）は重要で間違いなく影響力のある書籍でした。しかし、ときに私はその簡潔なルールが本来意図した哲学の簡潔な表現としてではなく、良いスタイルにするためのクックブック的な手法として捉えられていると感じます。もし、かの書籍が変数名は意味があるように選ばれるべきだと主張するのであれば、変数名はその用途を説明したエッセイになっている方が良いということにならないでしょうか。 MaximumValueUntilOverflow は maxval よりも良い変数名でしょうか。私はそうは思いません。
従うべきは、厳しいルールを与えることではなく、プログラムを書く際の明確さの哲学を全体として助長するような短いエッセイです。みなさんにこれらすべてに同意してもらいたいわけではありません。なぜならこれは意見であり、意見は時間とともに変化するものだからです。しかし、私の意見は頭のなかにしばらくあったものをまとめたものであり、長らく文章として公開してきませんでした。またこれらは私の多くの経験を踏まえたものです。そのため、プログラムの細かな部分に関する計画方法の理解に役立てば幸いです。（これまでプログラム全体の計画に関しての良い文章は読んだことがありますが、それらはこの文章で触れる内容の一部となります）もしいまから紹介するものを特異だと感じたのであれば、それはそれで結構です。また同意できないとしても、それも結構です。しかし、なぜあなたがなぜ同意できないのかを考えるきっかけになったのであれば、より良いことでしょう。どのような状況においても、私がそういったからという理由で私が言ったやり方で書くべきではありません。あなたがそのプログラムで実現したいものを最も良く記述できると考える方法でプログラムしてください。そしてそれを一貫し容赦することなく行ってください。
あなたのコメントをお待ちしています。
表示の問題
プログラムは一種の出版です。プログラムはプログラマや他のプログラマ（おそらく数日後、数週間後、数年後のあなた自身）、そして最終的にはマシンに読まれることを前提としています。マシンはそのプログラムがどれほど美しいかは気にしません。コンパイルできれば、それで幸せなのです。しかし、人間は気にします。そして気にすべきです。ときに気にし過ぎます。たとえば、pretty printerは機械的にプログラムの重要でない部分も強調するような美しい出力をします。これは、英語の文章内にある前置詞 を すべて太字 に するの と 同様 です 。しかしながら多くの人々がプログラムはAlgol-68 Reportのような見た目（システムによってはそのスタイルで編集することを強制します）であるべきと考えますが、明瞭なプログラムはそのような見た目で成されるものではなく、また悪いプログラムであれば明瞭にしても滑稽になるだけです。
もちろん表示に関する一貫した規約は見た目を明瞭にするためには重要です。インデントは最もよく知られ最も有用な例です。しかし、印字がプログラムの意図を曖昧なものにしてしまうのであれば、がやり過ぎだったということです。したがって、たとえあなたが昔ながらのタイプライターのような飾り気のない表示にこだわっているのだとしても、表示における愚かさを意識しましょう。余計な飾りをやめましょう。たとえばコメントは短く、バナーは無くしましょう。プログラム内で言うべきことを、綺麗に一貫して言いましょう。それから先に進みましょう。
変数名
そうですね、変数名です。変数名の長さは美徳ではありません。表現の簡潔さが大事なのです。滅多に使われないグローバル変数は長い名前にしてもいいでしょう。たとえば maxphysaddr といった具合です。ループ内のすべての行に出現する配列のインデックスは i 以上に凝った名前を付ける必要はないでしょう。たとえば index や elementnumber といった変数名はタイプ量（あるいはエディタ内で呼ばれる回数）が増え、計算の内容を不明瞭にします。変数名が巨大な場合、何が起きているかを把握するのが難しくなります。これは表示に関する問題の一部です。
for(i=0 to 100)
array[i]=0
というコードと
for(elementnumber=0 to 100)
array[elementnumber]=0;
というコードを見比べてみましょう。
現実の例では問題はもっと速く明らかになります。インデックスはただの注記なので、そのように扱いましょう。
ポインタもまた気が利いた注記が必要です。どの np が "node pointer" を意味しているかがすぐに分かる命名規則を一貫して使っていれば、 np は nodepointer という名前と同じくらい読みやすいものになります。
プログラムの可読性に関していえば、命名において一貫性は重要です。ある変数に maxphysaddr と名づけたら、同様の変数に lowestaddress という名前をつけてはいけません。
最後に、私は最短の名前ではなく最も情報量がある名前を好み、ほかは文脈に任せる方法を好んでいます。たとえば、グローバル変数は典型的には使われる際にはほとんど文脈がないので、名前は比較的それだけで内容がわかるものである必要があります。したがって、グローバル変数名には maxpysaddr （ MaximumPhysicalAddress ではありません）という名前をつけ、ローカル変数には NodePointer ではなく np のような名前をつけます。これは好みによるところが大きいですが、その好みというのは明瞭さに関係するものです。
名前に大文字を入れるのも避けています。散文調の文章を見慣れた私には、大文字が文章の中に入ると不格好に感じられ快適に読めないのです。大文字は悪い印刷のように目障りなのです。
ポインタの使用
C言語はポインタでなんでも指せるという点で特異です。ポインタは賢い道具で、他の同様の道具のように、上手に使えば楽しく生産的になりえるものの、使い方を間違えると大きな損害を与えます。（この文章を書く数日前に木工彫刻刀で親指を怪我したばかりです。）ポインタは危険すぎる、あるいは汚すぎると考えられ、学術会では評判が良くありません。しかし私はポインタは強力な 注記 であると考えます。つまり、ポインタは明瞭な表現をする手助けをしてくれるという意味です。
次の状況を考えてみてください。あるオブジェクトに対するポインタがあるとき、それはまさにそのオブジェクトに対する名前であり、他のなにものでもありません。些細なことのように思えるかもしれませんが、次の2つの表現を見てください。
np node[i]
最初のポインタはノードを指していて、2番目は（たとえば）同じノードを評価しています。しかし、2番目の形式は式です。単純ではありません。これを理解するためには node が何か、 i が何かを理解し、そして node と i がどのような関係にあるか（おそらく明記されていない）を周りのプログラムから理解しなければなりません。独立した式それだけでは i が node の正しいインデックスかはわからないですし、ましてそれが私達がほしい要素のインデックスかはわかりません。もし i と j と k のすべてがノードの配列のインデックスだった場合、容易にうっかりと間違えてしまいます。特にサブルーチンに渡すときは間違いを起こしやすく、コンパイラでは避けようがありません。ポインタであれば1つのものを指しています。配列とインデックスは受け取ったサブルーチン側がお互い関係があるものとして信用しなければなりません。
オブジェクトに評価する式は、オブジェクトのアドレスよりも本質的により判断しづらく間違いを起こしやすいものです。ポインタを正しく使うことでコードを簡潔にできます。
parent->link[i].type
と
lp->type
を見比べてください。
もし次の要素の型が必要な場合は
parent->link[++i].type
よりも
(++lp)->type
のほうが見やすいでしょう。
i は値が進みますが、それ以外はなにも変化がありません。ポインタであれば進めるのは1つのものだけです。
ここでも表示の問題が出てきます。ポインタを使って構造を読み込むのは式を読むよりも理解が楽です。必要なインクの量は少なく、コンパイラやコンピュータが展開する労力も減ります。関連した問題として、ポインタの型が正しく使われているかに影響を与えているかというものがあります。これでコンパイル時に配列のインデックスが適切で無い旨のエラー検出が可能になります。また、そのオブジェクトが構造体の場合はタグとフィールドは型を思い出させてくれます。つまり
np->left
はそれぞれが何を挿すかを思い出させるのに十分です。これがもしインデックスが指定された配列であれば、配列名はきちんと選ばれた名前で、表現は長くなります。
node[i].left
再度になりますが、余計な文字は表現が大きくなるにつれて苛立たしくなります。
ルールとして、もし同様の表現を含むコード、たとえばデータ構造の要素を評価するような複雑なデータ構造があった場合、思慮深くポインタを使えばすっきりとできます。
if(goleft)
p->left=p->right->left;
else
p->right=p->left->right;
p の複合的な使い方をしているこのコードが何をしているかを考えてみましょう。時には一時変数（この場合は p ）を使用したり、計算の本質を抜き出すマクロを使用する価値があります。
プロシージャ名
プロシージャ名はそれが何をするかを反映すべきです。つまり関数名はそれが何を 返すか を反映すべきです。関数は式の中で使われ、しばしば if の中で使われます。したがって適切に読む必要があります。
if(checksize(x))
という記述は役に立ちません。なぜならchecksize関数がエラーの時にtrueを返すのか、エラーでない時にtrueを返すのかが推測できないからです。代わりに
if(validsize(x))
とすれば要点が明らかになり、将来同じ関数を使うときの間違いが起こりにくくなるでしょう。
コメント
慎重に、経験と判断をもって書く必要があります。私は、いくつかの理由から、コメントを極力書かないようにしています。まず、コードがきれいで、良い型名や変数名を使っている場合、コードそれ自身が内容を説明しているはずです。次に、コメントはコンパイラにはチェックされないので、コメントが正しいという保証はありません。特にコードが変更されたあとはそうです。誤解を招くコメントは非常に紛らわしいものです。最後に、表示の問題です。コメントはコードを散乱させてしまいます。
しかし私も時々コメントを書きます。ほとんどもっぱらその後に何が続くかを説明するために書きます。例えば、グローバル変数の使い方とその型の紹介（大きなプログラムではいつもコメントするものの一つ）、通常の使い方をしていないプロシージャや非常に重要なプロシージャの紹介、あるいは大きな計算をする際の区切りなどです。
悪いコメントの例としては次のようなものがあります。
i=i+1; /* Add one to i */
さらに悪いコメントの例は
/********************************** * * * Add one to i * * * **********************************/ i=i+1;
いまこの例を笑ってはいけません。実際にこのようなコードに出くわしたらはじめてそこで笑いましょう。
複雑さ
たいていのプログラムは複雑過ぎます。つまり、問題を効率的に解決するために必要な複雑さよりも複雑なのです。なぜでしょう。多くの場合、それは設計の悪さに起因しますが、ここではその話は大きすぎるテーマなので触れません。しかし、プログラムはしばしば細かなレベルでも複雑で、ここではその点についてお話します。
ルール1 プログラムのどこに時間がかかる場所があるかはわからない。ボトルネックは思わぬ場所で起きる。したがって、どこがボトルネックかわかるまでは、合理的な判断なしに余計な勘ぐりをしたり高速化のためのハックをするのはやめよう。
ルール2 計測しよう。計測するまでは高速化のためのチューニングはやめよう。さらに、高速化のためだとしても、プログラムの残りの部分を圧倒するような場合でない限り、チューニングはやめよう。
ルール3 n が小さい時にはしゃれたアルゴリズムは遅く、そして通常 n は小さい。しゃれたアルゴリズムではその影響が現れるコンスタントな値は大きい。 n が頻繁に大きくなるとわかるまでは、手が込んだアルゴリズムは使わないようにしよう。（たとえ n が大きくなるとしても、まずはルール2を考えよう）たとえば、日常的な問題では二分木は常にスプレー木よりも速い。
ルール4 しゃれたアルゴリズムは単純なアルゴリズムよりもバグを起こしやすい。そして実装がずっと難しい。単純なアルゴリズムと単純なデータ構造を使おう。
次に挙げるものはほぼすべての実用的な問題を解決するデータ構造の一覧です。
- 配列
- 連結リスト
- ハッシュテーブル
- 二分木
もちろん、これらのデータ構造を組み合わせたデータ構造にすることも配慮しなければいけません。たとえば、シンボルテーブルは文字型の配列の連結リストを含んだハッシュテーブルとして実装されているでしょう。
ルール5 データが支配する。正しいデータ構造を選び、物事をうまくまとめれば、それを使うアルゴリズムは自明である。アルゴリズムではなく、データ構造がプログラムの中心である。（詳しくは「人月の神話」を参照のこと）
ルール6 ルール6はない。
データでプログラミングする
アルゴリズム、つまりアルゴリズムの細かな部分は、しばしばデータという簡潔で、効率的で、表現豊かな形に記号化されます。それは、たとえば、多くのif文という形ではありません。その理由は、もし手元にある 複雑さ が独立した細かな部分の組み合わせによるものなのであれば、それは 記号化できるから です。古典的な例で言えば、表のパースです。これはプログラミング言語の文法を、定形のかなり単純なコード片によって説明可能な形式に記号化することです。特にこのような問題に取り組むときには有限状態機械が採用されていますが、ある抽象的な入力を「パース」して一連の独立した「振る舞い」に変換するようなあらゆるプログラムは、ほとんどが生産的な形としてデータ駆動のアルゴリズムになります。
おそらくこのような設計の最も魅力的な側面は、ときどき表が、古典的な例ではパーサジェネレータといった、他のプログラムに生成されることです。もっと現実的な例では、オペレーションシステムが、I/Oのリクエストとそれに対する適切なデバイスドライバの組み合わせを持ったひとまとまりの表によって動いているとした場合、システムはマシンに接続されたある特定のデバイスの説明を読み込み、対応する表を表示するようなプログラムによって「構成される」でしょう。
データ駆動プログラムが一般的でない理由の一つは、少なくとも初心者においては、Pascalによる圧政でしょう。Pascalは、その創始者のように、コードとデータの確固たる分離を信条としています。したがって（少なくとも本来の形では）初期化されたデータを作ることはできません。このことはチューリングとフォン・ノイマンの理論の前にはたち消えてしまいます。この理論はストアドプログラム方式のコンピュータの基本原理を定義しています。コードとデータは同じものです。あるいは少なくとも同じになりえます。それ以外にどうやってコンパイラが動作するかを説明できるでしょうか。（関数型プログラミング言語でもI/Oにおいて同様の問題を抱えています。）
関数ポインタ
Pascalの圧政は、初心者が関数ポインタを使わない、という状況ももたらしています。（Pascalでは関数を値にもった変数を持つことができません。）複雑さを記号化するために関数ポインタを使うことにはいくつか面白い特性があります。
複雑さのいくつかは参照先のルーチンに渡されます。そのルーチンはいくつかの標準的な規約に従わなければいけません。そのルーチンは同じ呼び出し方をされたひとまとまりのルーチンの一つです。しかしそれ以上にそのルーチンは自分がすべきことしかしません。複雑さが 分散された のです。
この規約という考え方があり、そこでは似たような使われ方をする関数はすべて似たような振る舞いをしなければいけなません。これによって、ドキュメントが書きやすくなり、テストがしやすくなり、コードを成長しやすくし、さらにはプログラムをネットワーク越しに分散させて稼働させやすくなります。この規約はリモートプロシージャコールとして記号化されます。
私は、関数ポインタを明確な形でつかうことがオブジェクト指向プログラミングの心であると、主張します。あるデータに対してひとまとまりの操作を行いたい、かつ、それらの操作に対してひとまとまりのデータ型を返したい場合、そうプログラムする簡単な方法は各型に対して関数ポインタをまとめることです。これは、一言で言えば、クラスとメソッドを定義することです。もちろん、オブジェクト指向言語は優れた構文、派生型などといった、より多くのものを提供してくれます。しかし、概念的にはオブジェクト指向言語は先のものにほんの少しのおまけを提供してくれるだけです。
データ駆動プログラムと関数ポインタを組み合わせが、プログラムの驚くほど表現豊かな書き方へと導いてくれます。私の経験から、その書き方はしばしば嬉しい喜びももたらしてくれます。たとえ特別なオブジェクト指向言語がなくても、余計な手間をかけずに、オブジェクト指向の90%の恩恵を授かることができ、結果をより管理することができるようになります。より高度な次元の実装方法を推奨することはできません。私がこのようなやり方で書いてきたすべてのプログラムは、その後の多くの開発のあとも快適に動作しています。規律が少ない手法で開発されたものよりもずっと良く動作しています。以上です。この手法が強制する規律は、長い目で見て大きな利益をもたらします。
インクルードファイル
単純なルールです。インクルードファイルは決してインクルードファイルをインクルードすべきではありません。代わりに（コメントや暗黙的に）まずどのファイルがインクルードされるべきか宣言した場合、どのファイルをインクルードするかという問題はユーザ（プログラマ）側に押し付けられますが、ある意味では管理がしやすくなり、ビルド時に複数のインクルードを避けることができます。複数のインクルードはシステムプログラミングでの悩みの種です。一つのCのソースファイルをコンパイルするのに5回以上もインクルードされたファイルがあることは珍しくありません。Unixの /usr/include/sys はこの点でひどいものです。
1つのファイルが2度呼ばれないように #ifdef を駆使する方法がありますが、普通は間違った結果となります。 #ifdef はインクルードされるファイルの中にあり、インクルードする側にはありません。その結果、しばしば何千行もの不要なコードが字句解析器に渡されることとなり、これは（良いコンパイラでは）最もコストが高いフェーズとなってしまいます。
単純なルールに従いましょう。
本文に出てきた書籍
- 作者: Brian W.Kernighan,P.J.Plauger,木村泉
- 出版社/メーカー: 共立出版
- 発売日: 1982/06/20
- メディア: 単行本
- 購入: 1人 クリック: 166回
- この商品を含むブログ (27件) を見る
- 作者: Jr Frederick P. Brooks,滝沢徹,牧野祐子,富澤昇
- 出版社/メーカー: 丸善出版
- 発売日: 2014/04/22
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (5件) を見る
