はじめに

藤原 博文 「Cプログラミング診断室」を読んだ。

最近 C コンパイラを自作していて、ソフトウェア開発の歴史に興味が湧いている。 その中で昔のソフトウェア開発の現場を少しでも感じたくてこの本を読んだ。

この本は 1991 年から 1993 年にかけてソフトウェアデザインに掲載された記事をまとめたものである。 1989 年に C 言語の最初の標準化（ANSI 標準）が行われたので、それから 2~4 年経った時期に書かれた文章である。

1980 年代は BASIC が主流で、1990 年代になって UNIX の発展に伴って C 言語が流行り始めた理解している。 そのため 1990 年代前半は BASIC 時代の GOTO 文を多用してグローバル変数に状態を撒き散らすおじさんが、 C 言語を書き始めたという時期なのかなと思っている。 そういう時代背景から、こういった企画が立ち上がったのだろう。（ほとんど想像です。）

内容全体はこちらから無料で読むことができる。私は図書館で借りて読んだ。

メモ

この本の面白さは、ソフトウェア開発において気をつけるべきことが書いてあることではなく著者の愚痴が書いてあることにあるが、それはさておき、この本を読んで今後意識したいことを忘れないように纏めておく。

変数名は省略しない

変数名を一文字にしない。 英語でもローマ字でもかまわないから、フルスペルに近いものにする。

関数は短く

関数は 60 行以内に。100 行を超えたら必ず分割。 理由は長い関数はパソコンの画面に収まらないから。

設計とは

この本は徹底的にフローチャートによる設計を批判している。

goto 文と同様に諸悪の根源とされているフローチャートを業務に使っている職場 が存在していたとは恐ろしいことです。

フローチャートは、「ソフトウェア考古学」の対象であり、情報処理技術者 試験の中にだけ今だに残っているものです。

私の感覚ではフローチャートって実質的 GOTO 文だし、現代の安全なプログラミング言語とは全く合わないと思う。

設計技法、開発技法の本はいっぱい出版されています。フローチャート以外の方法について、概略で十分ですから、何か適当な本を読んでおくことは重要です。

設計とは、目的の処理をどうやって実現するか、どう関数に分解するかなどの「意図」や「全体 の流れ」を書きあげるものです。

設計の表現方法は複数ある。設計は所詮人間同士のコミュニケーション手段なのだから、伝わらない設計を作るより伝わる設計を作るべきだと思う。

データ構造を書く

データ構造はしっかり書くべきだと言っている。

プログラムは、データを処理するためにあり、データの違いによって制御の流れ が変更されます。あくまでも、データが主体です。変数、引数などのデータをどう定義するかで、 プログラムの組易さは大幅に改良されます。データ構造がどうなっているかの図の方が、フローチャー トよりはるかに役立ちます。データの意味だけはしっかり書きましょう。

大抵のプログラムは逆アセンブルすると mov 命令が最も多く使われているし、コンピュータとはデータを処理する機械らしい。

main は短く

main 関数はせいぜい数個の関数を呼び出すだけにする。

楽をする

C 言語にも文字列操作の関数はたくさん用意されているので、それを使ってなるべくコードを書かないようにする。 現代だと AI 使って調べる。

関数の引数を使う

なるべく関数の引数を使って処理する。グローバル変数に状態を撒き散らさない。

GOTO 文

著者は GOTO 文をエラーハンドルにだけには使っていいと言っている。 これは結構意外だった。 最近の言語は GOTO 文なんてないんだよなぁ。

おわりに

この本は非常に面白かった。30 年前のソフトウェアの本だけど今でも通用する内容が多く非常に意味のある本だと思う。 内容的にはリーダブルコードに似ているので、リーダブルコードを読んでもあんまり頭に入ってこなかった人はこの本を読んでみるといいと思う。 汚いコードは綺麗なコードを書く人にどう思われているか書いてあるよ。