• Brian W. Kernighan & P. J. Plauger, (1974,) 1978: The Elements of Programming Style. 2nd edition. McGraw-Hill.
• Brian W. Kernighan, P. J. Plauger 著, 木村 泉 訳, (1976,) 1982: プログラム書法 (第2版)。共立出版, 236 pp. ISBN 4-320-02805-5.[奥付では「4-」がぬけている。]

日本語版の第2版は 1982年に出版された A5判 横書きのペーパーバック。初版 (1976) もそうだったが、第2版のほうがやや厚くなった。

プログラム言語の入門書の例文のまちがったところや教材としてうまくないところを実例添削でしめした、計算機プログラミングの教材である。プログラム言語としては Fortran と PL/I (ピーエルワン) がつかわれている。Fortran は、77標準になるまえの、あとづけで「66標準」とよばれた規格によっている。ただし本書第2版では、77標準が出たが、それにそったコンパイラはまだ普及していない時点だったので、77標準にしたがえばよりよくなるところを注釈的にのべている。

本書の主要な主張のひとつは、プログラムを読む人にわかりやすく書こう、ということである。

もうひとつは、制御構造を明確に表現しようということであり、初版ではわざとその用語をさけていたそうだが、「構造プログラミング」とよばれる態度である。(この用語は英語の structured programming にちがいなく、わたしは「構造化プログラミング」とする。) 本書 (第2版) 第3章の主題であり、第2章の話題も半分ぐらいはこれである。手順立て型の (多くのプログラム言語教科書では「手続き型」とされている) プログラムは、順次処理、条件別処理、ループの 3つの構造で書くことができ、そのほうが見通しがよい。条件別処理については、PL/I にはすでに IF … THEN … ELSE があり、Fortran でも 77 ではこの構文 (ただし END IF をつかう) がつかえるようになった。77 よりまえの Fortran では「IF (…) GO TO …」の形をつかわなければならないことがある。ループについては、PL/I には DO WHILE … がある。Fortran にはながらく実行回数を決めた DO ループしかなく、条件がみたされるまでくりかえすには (77標準でもなお) GO TO が必要なことがある。しかし、GO TO をつかうにしても、条件分岐やループの構造をつくることを意識してつかうほうが見通しよく書ける。 [別ブログ記事 (2020-07-18) 「Go to をめぐって」] の後半に関連することを書いた。

第4章では、プログラムを部品にわけること、とくに。Fortran の subroutine という下請け手続きを記述する機能をどうつかうかを論じている。これも構造化といえるが、上にのべた制御構造とはレベルのちがう話題である。

第5章は入出力について。とくにプログラムがデータを読む際に、なるべくまちがいがおきにくいデータ形式にしたうえで、まちがいがおきたら検出して対処するようにプログラミングするべきである。

第6章は「よくあるまちがい」。いくつかの別々のことを言っている。変数を未定義のままつかってしまうと結果がさだまらないので、変数の値の初期設定をわすれないこと。浮動小数点演算ではそれが近似する実数についての等式がなりたつとはかぎらないこと。数値をある幅で変えて演算するときの境界の値や、不等号で分岐するときの等号の場合の動作に注意してプログラムをテストすること、など。

第7章は、プログラムの効率のこと。効率よりも正しく動作することを優先させるべきだ。効率が必要となったら、どこが時間をくっているか測定しよう。小細工よりもアルゴリズムを根本的に考えなおしたほうがよいこともある。

第8章は、プログラムへの注釈の入れかたについて。プログラム自体を、変数名をくふうして読みやすくし、実行内容をいちいち注釈しなくてもよいようにするのがよい。しかし、どんなデータをあたえることが期待されているかは書いたほうがよい。

わたしは本書でよいとされているプログラム例を、Fortran 77 に、さらに DO WHILE や 行番号なしの DO 文を追加した言語仕様で書きなおしてみた。個人ウェブサイトの [このページ] に置いてある。

いまでは、ひろくつかわれるプログラム言語がいれかわったし、Fortran の標準もあたらしくなった。プログラミングの教科書で、本書で批評対象となっているようなまずい文例はあまりないとはおもうが、いまどきなりのプログラミングスタイルの教材があったほうがよいとおもう。

折りかえしのあとに目次をつける。

===== 目次 =====
[Credits]
第2版まえがき
第2版訳者まえがき
第1版まえがき
第1版訳者まえがき
目次
1. はじめに
– わかりやすく書こう — うますぎるプログラムはいけない
2. 表現について
– いいたいことを単純率直にいおう
– ライブラリ関数を使おう
– 一次的変数はなるべく使わないこと
– わかりやすく書こう — 「効率」のためにわかりやすさを犠牲にしてはいけない
– よごれ仕事は機械にやらせよう
– 同じ表現の繰り返しは共通関数の呼び出しに変えよう
– かっこを使って誤解を避けよう
– 混同のおそれのない名前を使おう
– Fortranの算術 IF 文は使わないこと
– 無用の飛び越しはしないこと
– 言語のよい機能を生かし、わるい機能を避けよう
– 条件つきの飛び越しを論理式の代りに使ってはいけない
– 「電話テスト」でプログラムがわかりやすいかどうかためそう
3. 制御構造
– DO-END と字下げを使って文の群の間の区切りをはっきりさせよう
– IF-ELSE を使って、二つのことがらのうちの一方だけが起ることをはっきりさせよう
– DO や DO-WHILE を使ってループの存在をはっきりさせよう
– プログラムを上から下へと読めるようにしよう
– 多方向の枝分かれをするときは IF … ELSE IF … ELSE IF … ELSE … を使おう
– 基本的な制御構文を使おう
– まずわかりやすい擬似言語で書いて、そのあと目的の言語に翻訳しよう
– THEN-IF や 空の ELSE はなるべく使わないようにしよう
– ELSE GOTO や ELSE RETURN はなるべく使わないようにしよう
– 条件判定をしたら、できるだけ対応する動作をくっつけて示そう
– データの配列を使うことによって、繰り返し動作をしないですむようにしよう
– プログラムが簡単になるようなデータの表現を選ぼう
– 第1版ができたところでやめてしまってはいけない
4. プログラム構造
– 単位分解しよう。サブルーチンを使うこと
– 機能単位間の依存関係は目に見えるようにしよう
– 各機能単位は一つのことをうまくやるように作ろう
– 機能単位はたしかに何かを隠すように作ろう
– データの構造に合わせてプログラムの構造をきめよう
– だめなプログラムを修正するのはやめて、全部書きなおそう
– 大きいプログラムは小部分ごとに書き、テストするようにしよう
– 再帰的に定義されたデータ構造を扱うときは再帰手続きを使おう
5. 入出力について
– 入力の妥当性、現実性をチェックしよう
– 入力がプログラムの限界を決して越えないよう注意
– 入力の終りはファイルの終り、または印によって示そう。入力回数の指定によるのはよくない
– まちがった入力をみつけ出そう。できれば回復のための処置をとること
– ファイルの終りは統一的に扱おう
– 入力形式は作りやすいように、出力形式は一目で理解できるようにきめよう
– 統一的な入力書式を使おう
– 読み合わせのしやすい入力形式を選ぼう
– もし可能なら自由欄形式の入力を使おう
– 見ただけで意味がわかるような入力形式を使おう。省略時の解釈ができるようにしよう。入力値と標準値を打ち出そう
– 入出力はサブルーチンの中に閉じ込めよう
6. よくあるまちがい
– すべての変数を、使う前に忘れず初期設定しよう
– 一つ虫をみつけたところで追及をやめてしまってはいけない
– 虫取り向きコンパイラを使おう
– 定数は DATA 文または INITIAL 属性で、変数は実行文で初期設定しよう
– 一つちがいの誤りに注意
– 比較の結果が等しいと出たとき、正しい方向への飛び越しが起るように注意しよう
– ループからいろいろな飛び出しかたをするのはやめよう
– 「何もしない」はずのとき変なことが起らないように注意しよう
– プログラムを境界値でテストしよう
– 予防的プログラミングをしよう
– 0.1 の 10.0 倍はまず決して 1.0 にはならない
– 浮動小数点表示の数を等しいかどうかのみに着目して比較してはならない
7. 効率と性能測定
– 速くする前に正しくしよう
– 速くするときは正しくなくならないように注意しよう
– 速くする前にわかりやすくしよう
– 「効率」がちょっぴりもうかるからといってわかりやすさを犠牲にするのはやめよう
– 簡単な最適化はコンパイラにやらせよう
– プログラムのどこかとどこかを兼用しようと思ってがんばってはいけない。むしろ組み立てなおしてみよう
– 特別の場合がほんとうに特別の場合かどうかたしかめよう
– 速くしたかったら単純さを保とう
– 速くしようとしてプログラムをひねくりまわすのはやめて、もっとよいアルゴリズムをみつけよう
– プログラムには測定手段を含ませよう。「効率」のための手なおしの前には測定をしよう
8. 解説文書
– 注釈とプログラムが一致するように気をつけよう
– プログラムに書いてあることを注釈でおうむがえしにするのはよそう。つけ甲斐のある注釈をつけよう
– だめなプログラムに注釈をつけるのはよそう。プログラムの方を書き換えよう
– 意味のある変数名を使おう
– 意味のある名札を使おう
– プログラムの割り付けをくふうして、理解しやすくしよう
– プログラムの論理構造を反映するような字下げをしよう
– データの割り付けかたについての解説をつけよう
– 注釈をつけすぎないようにしよう
エピローグ
参考書目
規則集
訳語対照表
索引
==========