satoru-t 氏がこの前のドイツ人の講演を聞きに行って 「読むことは大事だ」と感銘を受けていた。 CODE COMPLETE にもじっくりマニュアルなどを読むことは大切だと書いてある。 さあて、読むか ( こんなものより論文読めよというつっこみは無しね )。
327 個の質疑応答。知らなかったことが多く、非常にためになった。 書籍版 は 460 個で 3600 円。 差分の 170 個の質疑応答は必要不可欠であるとの確信がないので、 今のところ買わない方針。
file:/home/is/tatuo-y/doc/cfaq-1997-09-08.txt
やたらと脚注が多いぞ。こんなことが書いてあった。
ファイルの中に書く順番： 1. include, 2. 解説, 3. typedef と define, 4. global, 5. 関数。 ヘッダファイルはネストすんな。 コメントは grep で分かりやすいスタイルにせよ (下の例を見よ)。 関数の中のコメントはタブれ。 関数宣言はこんな感じ。
/*
* コメントの各行は '*' から始まる
*/
int /* TRUE or FALSE */
skyblue()
{
extern int hour;
後の人のために extern で明確化。 portability: サイズの問題があるから x &= 017770 はダメ、 x &= ~07 を使え。
file:/home/is/tatuo-y/doc/ihstyle.ps
The Practice of Programming でおなじみの Rob Pike 氏のプログラミングスタイルについてのエッセイ。 全 5 ページで短く、読みやすく、面白いのでおすすめ。 こんなことが書いてあった。
意味のある名前を付けろとかいうけど、 maxval より MaximumValueUnitOverflow が良いなんて思わん。 長い名前は却って何をやっているのかわかり難くなる。 ポインタは評判悪いけど、表現を明確にしてくれる強力な道具だ。 procedure は「何をするか」、 function は「何を返すか」を基準に名前を付けるべきだ。 × if(checksize(x))、 ○ if(validsize(x))。 あんまりコメントを書かない理由： (1) コードが明解で名前も分かりやすかったら不要だから。 (2) コメントはコンパイラでチェックされないので正しさの保証が無い。 (3) コメントはコードを取り散らかす。 理解のために必要なコメントを書くよりも、 理解しやすいようにコードを書き直した方が良い。
file:/home/is/tatuo-y/doc/pikestyle.ps
UNIX USER 10 月号はゲーム特集だったんだけど、 パズルゲーム IGUSTA が画像入りでしっかり載ってた。 他のゲームと比べると見劣りするなあ。
学生課からメールが来た。 日本育英会奨学金返還説明会が 26 日開かれる。 場所はバイオサイエンス研究科棟１階大講義室。 情報 M2 は 13:30 〜 14:30、情報 D3 は 15:00 〜 16:00。