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

Programmer's Note

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

読書:ソフトウェア作法(英語編)

ブログ記事:読書:ソフトウェア作法 - Programmer's Dialy で「ソフトウェア作法」について書いたが、原書を買った。
やっぱ直接Kernignhan & Plaugerの言葉を読みたい。Amazonでさくっと買えちゃうなんていい時代。(一方、読んでみると日本訳も実に丁寧だというのが分かった。)

Software Tools

Software Tools


前に引用した同じ箇所を英語でも引用して、もう一回読む。

It may seem silly to write a five-line function to be called only once, but the purpose of settab is to conceal a data representation from a routine that does not have to know it.
...
it is vital to break larger program into small pieces that communicate only though well-defined interfaces. The less one part of a program knows about how another part operates, the more easily each may be changed.

うん、"communicate only through well-defined interfaces"がキーですね。
そして、well-defined interfaceを設計するのって一番難しいとこだ。

By writing a program in a straightforward manner, you get it working correctly and minimize the change of confusion. You can then measure how it performs to decide whether it works well enough and, if not, where to concentrate your attention.
...
Sacrifice clarity for speed only when you know that you are solving the correct problem correctly and when you know that the sacrifice is worthwhile.

これは基本中の基本。まずは素直に書き、十分正しく動くことを確認した後に、さらにmeasureして十分でない場合に限り、スピードを考えろと。
この本が書かれた1976年はちょうどUNIX V6の時期。本書の冒頭にプログラムの動作確認にIBM 370, Honeywell 6070, PDP-11を使ったとある。
今と比べ物にならないくらいマシンが遅い時代に、おそらくアセンブラゴリゴリの誘惑に負けそうなのが普通だというところに、この言葉はすごいなと。

But our primary tool for writing good program is to strive to make them readable. In our experience, readability is the single best criterion of program quality: If a program is easy to read, it is probably a good program; if it is hard to read, it probably isn't good.

リーダビリティ"readability"の重要性を、the single best criterionて本当に強く主張している感じですね。

原書の雰囲気はたまらんものがある。(浸って読むって重要だよなあ)
日本語訳もすばらしいというのが改めて分かったので、続けて読みたい。