3. 一般的なプログラムのデザイン

この節では、 プログラムを設計するときに気を付けるべき話題をいくつか議論する。

3.1 他の実装との互換性

ときには例外もあるが、GNU用のユーティリティプログラムやライブラリは、 バークレーUnixの上位互換であるべきで、ANSI Cがその振る舞いを規定 しているなら、ANSI Cの上位互換に、POSIXがその振る舞いを規定 していれば、POSIXの上位互換であるべきだ。

もしこれらの標準が矛盾していたら、それぞれに対し互換モードを提供する と便利だ。

ANSI CやPOSIXはたくさんの拡張を禁じている。拡張をどんな風に 行っても構わない、そうして、それを使わないための、`--ansi'とか `--posix'とか`--compatible'オプションを含めなさい。 しかしながら、その拡張が実際のプログラムやスクリプトをおかしくする、 十分な可能性があるなら、それは本当のところ上位互換ではない。そのインタ ーフェースを再設計してみなさい。

多くのGNUプログラムは、環境変数POSIXLY_CORRECTが定義されている と(例え、それは空の値と定義されていても)、POSIXと抵触する拡張を 行わない。適切であれば、あなたのプログラムをこの変数を認識するように してください。

ある機能が(プログラムやコマンド・ファイルではなく)ユーザだけに使われ、 かつ、それがUnixでは貧弱なものなら、それをまるで違った、もっと良いもの に完全に置き換えてしまってよい。(例えば、viはEmacsと置き換えら れている。) しかし互換機能も提供するのが良い。(フリーなviクローン があるので、我々はそれを提供する。)

バークレーUnixにはない、便利な機能の追加は歓迎である。

3.2 標準的でない機能の使用

すでに存在する、たくさんのGNUの機能は、相当するUnixの機能以上の便利な 拡張を数多くサポートしている。あなたのプログラムを実装する中でそれらの 拡張を使用するかどうかは難しい問題だ。

一方、その拡張を使用することで、より美しいプログラムを作ることができる。 他方、他のGNUツールが手に入らなかったら、人々はそのプログラムを構築で きないだろう。このために、そのプログラムはより少ないマシンでしか動かな くなるだろう。

いくつかの拡張によって、代わりのものも提供するのが容易であるかもしれな い。例えば、"キーワード" INLINEを定義し、コンパイラによって、 inlineか中身のないマクロに展開させることができる。

一般的に言って、おそらく、拡張を使わずに平易に書けるならそれらを使わな いのが最善で、大きく改善されるなら拡張を使うのが最善だ。

この規則の例外は、非常にたくさんのシステムで走る、(Emacsのような)大き くて完成されているプログラムだ。そのようなプログラムでは、GNUの拡張の 使用によって、上手く行かなくなってしまうだろう。

別の例外は、コンパイル過程の一部として使われるプログラムだ。GNUコンパ イル環境の機能を立ち上げるために、他のコンパイラによってコンパイルされ なければならないものはどんなものでも。もしこれらがGNUコンパイラを必要 としていると、すでにインストール済みでない限り、それらをコンパイルする ことは誰にもできない。これは良くないだろう。

3.3 ANSI CとANSI以前のC

決してANSI Cの "trigraph" 機能(2)を使っては ならない。

ANSI Cは、今ではもうANSI Cの機能を使う(それゆえnon-ANSI コンパイラでは動かない)新しいプログラムを書いていいぐらい広まっている。 そして、もしプログラムがすでにANSI Cで書かれているなら、それを non-ANSIコンパイラをサポートするよう変換する必要はない。

しかしながら、ほとんどのプログラムではnon-ANSIコンパイラをサポー トするのは容易だから、プログラムを書くときにはそうするよう心掛けてもよ いだろう。ANSIプロトタイプ形式での関数定義、

int
foo (int x, int y)
...

を書く代わりに、このようなANSI以前の形式で定義を書きなさい。

int
foo (x, y)
     int x, y;
...

そして、引数のプロトタイプを特定するのに、別に宣言しなさい。

int foo (int, int);

いずれにせよ、その関数を呼ぶ全てのファイルでANSI Cプロトタイプの恩恵 を得るためには、あるヘッダファイル内でそのような宣言を必要とする。 そして、それを一度書いてしまえば、ANSI以前の形式で関数定義を書く ことによって失うものは何もない。

もしあなたがnon-ANSI Cを知らないなら、それを勉強する必要はない。 ANSI Cで書けばいい。

3.4 C以外の言語の使用

C以外の言語の使用は標準的でない機能を使うようなものだ。ユーザは問題を 引き起こすだろう。例えGCCが他の言語をサポートしていても、ユーザは、 あなたのプログラムの構築するために、その他の言語のコンパイラをインスト ールしなければならないことを不便に感じるかもしれない。例えば、あなた のプログラムをC++で書いたら、人々はあなたのプログラムをコンパイルす るためにC++コンパイラをインストールしなければならないだろう。このよ うに、Cで書く方が良いのだ。しかし他の言語を使う欠点がない状況が3つあ る。

• その言語用のインタープリタをあなたのプログラムが含んでいるなら、他の言 語を使っていい。

  例えば、あなたのプログラムがGUILEとリンクしているなら、そのプログラム の一部をSchemeやGUILEがサポートする他の言語で書いても良い。

• その言語と一緒に使われることを特に意図しているツールでは、他の言語を 使って良い。

  そのツールを構築したい人々は、その他の言語をいずれにせよインストールしてい る人々だけだろうから、これで構わないのだ。

• もしそのアプリケーションが狭い集団に対して関心があるなら、おそらく そのアプリケーションのインストールが不便かどうかなど重要ではない。

CはC++や他のコンパイル用言語以上の利点を持っている。より多くの人々がC を知っている。だから、プログラムがCで書かれていると、それを読んだり変 更したりするのが、より多くの人々にとって容易だろう。