プログラム書法 第2版 / Brian W.Kernighan, P.J.Plauger

先日, 「プログラミング言語AWK」について書いたときに, この本も読まねば、と即手に入れて読んでます.

プログラム書法

Brian W.Kernighanと, P.J.Plauger の共著. 木村泉さんの翻訳.

原題は “THE ELEMENTS OF PROGRAMMING STYLE”.

共立出版から昭和51年初版発行. 45年も前に出版された本です.
第2版は昭和57年発行、それでも39年も前の本です.

共立出版のサイトを見ると絶版ではなさそうなのですが、こうやってAmazonから古本を購入できる時代となりました. 神保町など徘徊しなくても所望の本が買える、いい時代です.

ソフトウェアエンジニアが読むべき本のリストには本書が必ずエントリされる名著です.

…と言いながら今まで未読でした…不勉強ですみません…

話は違いますが, 共立出版の本は持ってるだけでなにかご利益がありそうですね.

目次

目次はこのようになってます.

  1. はじめに
  2. 表現について
  3. 制御構造
  4. プログラム構造
  5. 入出力について
  6. よくあるまちがい
  7. 効率と性能測定
  8. 解説文書

各章の解説に使われるプログラム例はFORTRANあるいはPL/Iで書かれていて、ここはさすがに時代を感じます.

ただ、40年前にかかれた内容でも現在に十分通用するところがあります.
プログラムの詳細な解説は読み飛ばして、各章の末尾のまとめ、規則を拾って読むだけでもためになると思います.

以降、本書で書かれている規則をいくつかとりあげてみます.

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

いずれにせよ、プログラムの意図を誤解の余地なく書きあらわすことの方が、腕の良さをみせびらかすことよりたいせつなのだ。

…深い、まさにその通り. 

「おれは技術力あるんだぜ」、これ見よがしの難解コードを書く傾向にあります…

今プログラムを動かして製品として出荷するのと同時に、ソフトウェア資産として世に残すのであれば、「コードの可読性」はとても重要. ドキュメントは読まれるとは限りませんし…

「わかりやすく書こう。- 効率のために分かりやすさを犠牲にしてはいけない」

これは難しい問題です. システムのボトルネックがあるプログラムにある場合、それを解決する最適化するためにコードが難解になることもありがちです.

その最適化がホントに有効なのか、についても本書では言及されています.

ちゃんと測定して最適化の効果を検証すべきと書かれてます.

こちらの本でも、その最適は本当に必要なのか?というくだりがあります.

つまり、効きもしない最適化をするよりも分かりやすさを選べ、ということです.
大事です.

「よごれ仕事は機械にやらせよう」

なんかPyhtonのあの本の題名はここからとったのでしょうか?

人の手で間違えるよりも機械にやらせよう, ということですね.

「ライブラリ関数をつかおう」

新たに自前で書いた処理、実はすでに実績のあるライブラリが用意されていること、ありがちです. 車輪の再発明って言うんでしたっけ?

プログラムを書く前にすでに誰かがそれを書いてるかもしれません.
事前じライブラリを調べてみること、言語の種類を問わず重要ですね.

「『電話テスト』でプログラムがわかりやすいかどうかためそう。」

最初何のことかわからなかったのですが、要は、
「プログラムのロジックを電話で相手に説明して理解されるか、言葉だけで理解されるくらい分かりやすさが必要」、ということです。

繰り返しますが「わかりやすさ」は大切なんですね。

「だめなプログラムを修正するのはやめて、全部かきなおそう」

…そうやりたいところはやまやまなんですけど、既存の資産を使って開発するケースが多い現代、なかなか難しい話です…

「入力の妥当性、現実性をテストしよう」

これはしばしば設計、実装、テスト設計フェーズで抜けていて、後々バグになること多いです。

「一つの虫をみつけたところで追及をやめてしまってはいけない」

類似のバグは往々にして複数存在するものです…

「速くする前にただしくしよう」

処理のボトルネックは実は間違ったアルゴリズムによるもの、ということはありがちです.

「簡単な最適化はコンパイラにやらせよう」

近年のコンパイラの最適化は強力です. プログラムをあれこれいじくるよるも最適化オプションのほうが効果があることも少なくないです.

「注釈とプログラムが一致するように気をつけよう」

ときとして意味のない、見てわかるようなコードに注釈があったり、またコードと注釈の内容が一致しておらず読み手が混乱する場合がときたま見られます。

先に書いたとおり、プログラムは正しく動くことと同時に読んで「わかりやすい」ということが大事、注釈も分かりやすさに寄与することに注意が必要ですね.

40年も前の本なのに

読んでみてうなずくこと多い本、出版されて40年以上も前の本なのに何故なのでしょうか?

それは、本書が出版された40年後の今でも

人の手でプログラムが書かれている

からなのです.

その昔、将来、自然言語を理解するコンピューター(第五世代コンピューター)が普及してプログラミングは不要になる、という将来が来る、と予想されました.
そんな未来は未だ来てません.

基本的に時代が変わっても人は変わらない、その人の手でプログラムが書き続けられる限り、この本にかかれていることから逃れられない、と思ってやみません…