A:
K&Rである。しばしば転載される良い例を載せているだけでなく、避 けるべき悪い例には、立派な理由も載せている。
カッコの位置はたいして重要ではない。ただし人はカッ コの位置に強い信念を持っている。我々は世にあるい くつかの例から選んだだけである。自分に向いている 書き方を取り入れて、首尾一貫して使いつづけること。大事なのはコードの配置が"完全な"ことよりも、選んだコードの配置を 首尾一貫して使うことである(それ自身、回りのコードと、あるいは共 通部と)。もし君がコーディングを行うときの環境が(たとえば職場の習 慣や会社の方針)コーディングスタイルを示していなくて、自分自身の 書き方を作り出す気もないのなら、単にK&Rをまねればよい。(さまざま な字下げや括弧の位置の持つ利点と欠点に関する調査は、徹底的かつ細 かく行うことができる。しかしここでは議論を繰り返さない。Indian Hillスタイルガイドを参照のこと)。
定義しにくい"よいスタイル"が持つ特質には、コードの配置の詳細以 上のものがある。もっと大事なコードの質の問題を抜きにして体裁に 時間を割かないこと。
質問10.6も参照のこと。
References:
K&R1 Sec. 1.2 p. 10; K&R2 Sec. 1.2 p. 10.
if(!strcmp(s1, s2))これはよい書き方?
とくによい書き方ということはない。ただし人気のある書き方ではあ る。このテストは、二つの文字列が同じときに成功する。しかしこの 形は等しくないことをテストしているようにみえる。
より優れた選択肢としては以下のようなマクロを使うことがある。
#define Streq(s1, s2) (strcmp((s1), (s2)) == 0)コーディングスタイルに関する考え方は、宗教に関する考え方と同じ で、議論に終りがない。よい書き方は価値ある目標であるし、たいて いは見ればよいか悪いかわかるが、文章にすることはできない。質問 17.10も参照のこと。
A:
これはよく以下のように書いてしまうことを防ぐためのコツである。
if(x = 0)
定数を==の前に持ってくる習慣を付けておけば誤って、
if(0 = x)
と打ち込むとコンパイラが文句を付けるどうやら2回=を打ち込むことを覚えるよりは、テストのオペランドの順をひっくり返す ことを覚えることのほうがやさしい。
(訳注:本のほうには、これは特によい書き方というわけではないと書 いてある。実際これでは両辺が変数の場合のif(a = b)という誤りを 捉えることはできない。こんな技を覚える暇があれば、lintの使い方 を覚えること。)
References:
H&S Sec. 7.6.5 pp. 209-10.
A:
printf()は値を返す。ただしprintf()の戻り値をわざわざ確かめるプロ グラムは数少ない。コンパイラによっては(lintも)戻り値を読まずに捨 てると警告を出すので、(void)に明示的にキャストすることは「はい、 この呼び出しの戻り値を無視することにしました。でも引き続きその他 の関数で戻り値を(うっかり)無視したら注意してください。」という意 志の1つの表現である。
strcpy()やstrcat()の呼び出しにもvoidのキャストはよく行われる。 これらの戻り値が、驚くような値になることはないから。
References:
K&R2 Sec. A6.7 p. 199; Rationale Sec. 3.3.4; H&S
Sec. 6.2.9 p. 172, Sec. 7.13 pp. 229-30.
A:
ハンガリー記法は名前の付けかたの取り決めで、Charles Simonyiが 発明した。これは変数の型を(おそらく、その使いみちも)変数の名前 に符号化する。一部のグループでは愛され、その他の人達からは容赦 なく酷評されている。主な利点は、データ型や意図する使い方が名前 を見ればわかるということである。主な欠点は、データ型は変数の名 前に付けて運んでまわるような大事な情報では必ずしもないことであ る。
References:
Simonyi and Heller, "The Hungarian Revolution" .
A:
さまざまな資料がanonymous ftpにより入手可能である。
| 場所・ファイルあるいはディレクトリ | 説明 |
|---|---|
| cs.washington.edu/pub/cstyle.tar.Z | (インディアンヒルガイドの改訂版) |
| ftp.cs.toronto.edu/doc/programming | (Henry Spencerの「Cプログラマーの十戎」も含む) |
| ftp.cs.umd.edu/pub/style-guide |
質問18.9も参照のこと。
A:
プログラミングの作法は文章作法と同じで、ちょっとした技能でガチ ガチの規則で明文化することはできない。ただし書き方についての議 論はもっぱらそういう規則を中心に回るようである。
goto文については、gotoを好き勝手に使うとすぐにスパゲッティのよ うにもつれた保守不能なコードになると昔からいわれている。しかし、 何も考えずに単にgoto文を使うことを禁止してもすぐに美しいプログ ラミングに結び付くとは限らない。体系立てて考えないプログラマー ならgoto文をまったく使わなくても同じように複雑怪奇にもつれたコー ドを書いてしまう(たぶん代わりに妙に入れ子になったループやブー ル値の制御変数を使って)。
プログラムの書き方に関するたいていの意見や"規則"は規則としてよ りは指針として考えたほうがうまくいく。プログラマーが、この指針 で何を成し遂げたいのか理解すればもっとうまくいく。ある種の構文 を無闇に敬遠したり、理解することなく規則に従うことは、規則を使 えば避けられることになっているのと同じくらい多くの問題を引き起 こす可能性がある。
さらに、プログラムの書き方に関する見解は所詮見解にすぎない。" 書き方論争(style wars)"に引きずり込まれても、たいてい何も産み 出さない。一部の論点(質問9.2, 5.3, 5.9, 10.7で挙げたような)に ついてはお互い相手の意見を認めたり、意見が違うことを認めたり、 議論を打ち切ったりすることはないように見える。