「プログラム書法　第二版」購入メモ

「プログラム書法　第二版」

Brian W.Kernighan and P.J.Plauger 著　　木村泉訳

（共立出版株式会社 ISBN 4-320-02085-5 C3041）

　著者の一人は、ＣプログラマにはK&R（「プログラミング言語Ｃ」） でおなじみのカーニハンで、昔から、同著者たちの「プログラム作法」と 合せて、名著として勧められている本です。 （訳本の第一版が1976年で第二版が1982年）

　プログラムの書き方についての本です。
　別段高度なことが書かれてるんじゃなく、段付け(インデント)しよう、 とか、紛らわしい名前をつけるのはやめよう、とかの、基本的なこと、 でも初心者のうちはあまり気にしないような、やりかた、とか、態度とか いったことがらを、実例を示しながら、いろいろ書かれてます。

まえがきから抜粋すると、

「よいプログラミングのしかたは、一般論を述べ立てることによって 伝えられるようなものではない。プログラムのよい書き方を学ぶ道は、 現実のプログラムが、プログラム書法の諸原則に従い、かつ、 いささかの常識を働かせることによって改善されて行くさまを、 繰り返し繰り返し眺めることにある」
「本書では、各例題の欠点を論じ、書き換えて改善し、そのあと 特定の例から一般原則を導き出す」
「この本は、初級と上級を問わずプログラミング関係のあらゆる レベルの講義における副読本として、また経験を積んだプログラマ向けの 知識整理のための読み物として、利用できる」

　ただ、書かれた時期の対象とした読者層の違いで使用言語が古い仕様 の FORTRAN と PL/I なのが、しかたないとはいえ現状を思うと 悔やまれる……Ｃなら人(後輩とか)に勧めれるのに(※)

　　「書法の原理は、いかなる言語にも、アセンブラ語についてさえ通用する」

　あと、普段使いなれない訳語が出て来たりしてちょっとだけ戸惑って しまうかもしれません。名札、とか、解説文章、とかは、今訳されたものなら、 ラベル、とか、コメント、とか書かれるんだろうな、と思うのですが。 "算譜"とかの独特の用語がでてくる本に比べれば面食らうことは ないけれども、それでも古めのプログラム本特有の雰囲気がちょっとは あるかもしれない。

　第一版からすれば20年以上たってるわけで、その後にも良書は出てる でしょうし、これに代る本もあるかもしれないし、入門書とかでも作法に ついて触れられていることも多いと思うんで、あえてこれを読め、って いうほどでも無いような気もする……が、この手のことを、まとめて述べた 本はそうなさそうな気もするし、あったとしても、これに代えることが 出きるものかどうか……と、思うと、やはり、この本がいいのかな(※)。

ひょっとしたら「書法」「作法」を読んだことある、って言えばカッコがつくかも （って、誰に対してだか）。

※ 現在では、言語として C/C++/java を据えてアップトゥデイトされた 『プログラミング作法』 が出ているので、今読む/買うなら断然こっちでしょう。

　とりあえず、巻末に、本文中に現れた規則を集めた規則集が巻末に が載っていたので下記にそれをかってに引用。
　実は、本文中に出てきた規則をまとめてやろうと、メモ打ち５つくらい した後に巻末にすでにまとまってることに気づいて、悔しいからそれ見て 打ちこんだだけ……てか、単に手で読んだときの残骸とも （しかし引用しすぎかなあ）。
　多少、本文見ずに規則だけみると、なんのことだろう、とか、 別のことと勘違いしそうなことがあるような気もするけど。 一般論の部分だけ抜き出したって、どうしようもないって面もありますが、 まあ、興味をもったり、とか、すでに経験からこれだけでも役立つとか いう人は、購入するのが吉ってことで。

規則集

　この規則集は、本書で述べたことの要点を手早く概観するためのものである。 これらの規則を読むときは、それらが一つ以上の実例をともなって 示されたものであった、ということを銘記してほしい。 もし規則を見て実例を思い出せなかったら、関係する部分に戻って、 読みなおしてほしい。
　参考書 The Elements of Style にある文句をもじっていうと、 プログラム書法の規則は、英作文の規則と同様、最良の作者によってさえ、 ときには破られることがあるものだ。 だが、規則がやぶられていたとしたら、プログラムの中にはその代償として、 何らかの利点が見出されるのが普通である。 たしかにこうしたほうがよいという確信がないかぎり、 規則を守っておくのがたぶん一番である。

• わかりやすく書こう。 ――うますぎるプログラムはいけない。

• いいたいことを単純素直にいおう。
• ライブラリ関数を使おう。
• 一時的変数はなるべく使わないこと。
• わかりやすく書こう。 ――「効率」のためにわかりやすさを犠牲にしてはいけない。
• よごれ仕事は機械にやらせよう。
• 同じ表現の繰り返しは共通関数の呼び出しに変えよう。
• カッコを使って誤解を避けよう。
• 混同のおそれのない名前を使おう。
• Fortran の算術 IF 文は使わないこと。
• 無用の飛び越しはしないこと。
• 言語のよい機能を生かし、わるい機能を避けよう。
• 条件つきの飛び越しを論理式の代りに使ってはいけない。
• 「電話テスト」でプログラムがわかりやすいかどうか試そう。
• DO-END と字下げを使って文の郡の間の区切りをはっきりさせよう。
• IF-ELSE を使って、二つのことがらのうちの 一方だけがおこることをはっきりさせよう。
• DO や DO-WHILE を使ってループの存在をはっきりさせよう。
• プログラムを上から下へと読めるようにしよう。
• 他方向の枝わかれを作るときは IF...ELSE IF ... ELSE IF ... ELSE ... を使おう。
• 基本的な制御構文を使おう。
• まずわかりやすい擬似言語で書いて、そのあと目的の言語に翻訳しよう。
• THEN-IF や 空の ELSE はなるべく使わないようにしよう。
• ELSE GOTO や ELSE RETURN はなるべく使わないようにしよう。
• 条件判定をしたら、できるだけ対応する動作をくっつけて示そう。
• データの配列を使うことによって、繰り返し動作をしないですむようにしよう。
• プログラムが簡単になるようなデータの表現を選ぼう。
• 第一版ができたところでやめてしまってはいけない。

• 単位分解しよう。サブルーチンを使うこと。
• 機能単位間の依存関係は目に見えるようにしよう。
• 各機能単位はひとつのことをうまくやるように作ろう。
• 機能単位はたしかに何かを隠すように作ろう。
• データの構造に合せてプログラムの構造を決めよう。
• だめなプログラムを修正するのはやめて、全部書きなおそう。
• 大きいプログラムは小部分ごとに書き、テストするようにしよう。
• 再帰的に定義されたデータ構造を扱うときは再帰手続きを使おう。

• 入力の妥当性、現実性をテストしよう。
• 入力がプログラムの限界を決して越えないよう注意。
• 入力の終わりはファイルの終わり、または印によって示そう。 入力回数の指定によるのはよくない。
• まちがった入力を美津家だろう。 できれば回復のための処置をとること。
• ファイルの終わりは統一的に扱おう。
• 入力形式は作りやすいように、 出力形式は一目で理解できるようにきめよう。
• 統一的な入力書式を使おう。
• 読み合わせのしやすい入力形式を選ぼう。
• もし可能ならば自由欄形式の入力を使おう。
• 見ただけで意味のわかるような入力形式を使おう。 省略時の解釈ができるようにしよう。 入力値と標準値を打ち出そう。
• 入出力はサブルーチンの中に閉じ込めよう。

• すべての変数を使う前に忘れずに初期設定しよう。
• 一つの虫をみつけたところで追求をやめてしまってはいけない。
• 虫取り向きのコンパイラを使おう。
• 定数はDATA文またはINITIAL 属性で、変数は実行文で初期設定しよう。
• 一つちがいの誤りに注意。
• 比較の結果が等しいと出たとき、正しい方向への飛び越しが 起こるように注意しよう。
• ループからいろいろな飛び出し方をするのはやめよう。
• 「何もしない」はずのとき変なことが起こらないように注意しよう。
• プログラムを境界値でテストしよう。
• 予防的プログラミングをしよう。
• 0.1の10.0倍はまず決して1.0にはならない。
• 浮動小数点表示の数おｗ等しいかどうかのみに着目して比較してはならない。

• 速くする前に正しくしよう。
• 速くするときは正しくなくならないように注意しよう。
• 速くする前にわかりやすくしよう。
• 「効率」がちょっぴりもうかるからといって わかりやすさを犠牲にするのはやめよう。
• 簡単な最適化はコンパイラにやらせよう。
• プログラムのどこかとどこかを兼用しようと思ってがんばってはいけない。 むしろ組み立てなおしてみよう。
• 特別な場合が本当に特別の場合かどうかたしけめよう。
• 速くしたかったら単純さを保とう。
• 速くしようとしてプログラムをひねくりまわすのはやめて、 もっとよいアルゴリズムをみつけよう。
• プログラムには測定手段を含ませよう。 「効率化」のための手直しの前には測定をしよう。

• 注釈とプログラムが一致するように気をつけよう。
• プログラムに書いてあることを注釈でおうむがえしにするのはよそう。 つけ甲斐のある注釈をつけよう。
• 駄目なプログラムに注釈をつけるのはよそう。 プログラムの方を書き換えよう。
• 意味のある変数名を使おう。
• 意味のある名札を使おう。
• プログラムの割付をくふうして、理解しやすくしよう。
• プログラムの論理構造を反映するような字下げをしよう。
• データの割り付けかたについての解説をつけよう。
• 注釈をつけすぎないようにしよう。