読者です 読者をやめる 読者になる 読者になる

Programmer's Note

コード読み書きの備忘録。

読書:ソフトウェア作法

読書

ソフトウェア作法

ソフトウェア作法

Kernighan & Plaugerの「ソフトウェア作法」 は古典的名著と言われていて読み始めたが、ほんとうに素晴らしい本だ。
goto文なしの構造プログラミングを紹介してるくらいの時代背景に、なんと関数を使ったデータ構造の隠蔽、テスト容易性を考慮した関数の切り出しについて語っている。
時代が時代だけに、日本語訳(用語)が古くさいが、、、そこは古典の雰囲気を味わえるということで^^;。

以下引用:

わずか5行の、しかも一回しか呼ばれない関数をわざわざ作るのはばかばかしいと思われるかも知れないが、settabの目的は、データ構造を隠して、それを知らないでよいルーチンには知らせないようにする、というところにあるのだ。
<中略>
もっと大きいプログラムの場合にはプログラムを細分化して、各部がはっきりした界面のみを通じて情報のやりとりをするように仕組むことは、きわめて重要である。プログラムの一つの部分がほかの部分の働きについて知っていることが少なければ少ないほど、それらの部分を変更することは容易になる。

界面というのはinterfaceのこと。つまり、データを隠蔽しそれにアクセスするモジュールを限定し、外には明確に定義したインタフェースを用意してアクセスさせる。(OOPそのものではないか)

そして、下手な高速化を考えるよりも、プログラムを分かりやすく書くことを最優先にすべきと説いている。ここはRobe Pikeも同じことをいっており「UNIX哲学」としても知られている。

プログラムをすなおに書けば、正しく動くものが得られやすく、混乱の生じる恐れも少ない。そうやってできたものの性能を測定して満足に動くかどうか調べ、もしまだ不満ならプログラムのどの部分に注意を集中したらよいかを見るが良い。
<中略>
正しい問題を正しく解いていることがたしかで、かつたしかに犠牲の払いがいがあると思うときに限って、わかりやすさをスピードのために犠牲にするがよい。

さらに別のくだりでも、以下のように言っている。

よいプログラムを書くためのもっとも有力な方法は、読みやすいプログラムを書こうと努力することである。経験によれば、読みやすさはプログラム品質に関する最高無二の判定条件である。プログラムが読みやすかったとしたら、それは多分よいプログラムなのだ。また、読みにくかったとしたら、それは多分だめなプログラムなのだ。

この本が書かれた時代ではFortranが全盛期だったらしい。この本ではFortranをベースに下Ratforという言語を定義している。そして、初めて知ったのだが、Fortranはgoto文しかなくて、while, if-else、for、とかまったくないらしい。

Fortranのプログラム例も乗っているが、なんともgoto文の分かりにくいこと・・・。
原書は40年ちかく前に書かれている。

構造プログラミングを創った先人たちの知恵に感嘆するとと同時に、プログラミングの本質は変わらないんだな。と。実に勉強になる。