C言語開発のノウハウがぎっしりつまった本である。
例えば、C言語で短いコードが、機械語で短い命令群になるとは限らないことを述べているところが気に入った。結果として、
「論理式に対しては”｜｜”を使用せよ。条件式に対しては？：演算子を使用せよ。
　条件文に対してはifを使用せよ。」
教訓を導き出している。
付け加えるとすれば、始めて各パターン、始めてコンパイルするコンパイラ（CPU)では、
１度はアセンブラに直して確認しなさいと書いて欲しかったかもしれない。
ps.
自動車向けのコーディング標準であるMISRA-Cでは十分カバーできていないところを、
本書では述べている点がいくつかあるようなので、併せて取り組むとよいと思った。
MISRA-Cでは、C言語の落とし穴とSafer-Cを参照している。
本書も参照文献の一つに加えるとよいと思う。

私はソフトウェア開発の仕事を始めてから20年以上になりますが、最近の傾向として、様々なAPIの習得が最重要とされ（仕事に必要なので止むを得ない）、「如何にコードを書くか」という、ソフトウェア技術者にとって最も重要な訓練が軽視されているような気がします。

以前はKernighanやPlaugerなどが書いた本を多くの技術者が読み、「コードの信頼性を如何に上げるか」、ということが多大な関心時でした。計算機資源が限られていたことや、オンラインデバッガが未成熟だったこともあり、初期のコードを如何に洗練させるか（要するに、バグの発生を如何に初期に食い止めるか）、ということに日々頭を悩ませたものでした。

今も勿論そうだとは思うのですが、誰でも一日中自身の計算機を使える環境にあること、オンラインデバッガの機能が著しく向上したことにより、とにかく早くコードを作り、バグが出ればその都度修正する、というスタイルに必然的に移行していると思われます。

C/C++は難しい言語で、ちゃんと訓練を受けた人でなければ扱えません。最近のソフトウェアの信頼性の低さは、C/C++が広まった割には、それを使いこなせる技術者が相対的に減っていることにあると、個人的には思っています。

本書だけで十分というわけではないでしょうが、現在軽視傾向にある問題を見つめる上で、再認識されても良い書物です。冒頭でKnuth（今知っている人がどれだけいる？）のTeXに関する文章が引用されていますが、これを理想とすることが現在正に望まれます。

この本を読むまで、バグの原因というものはデバッガでプログラムの挙動を追いかけながら見つけるものだと思い込んでいました。ところが、この本で紹介されていたのは、バグの検査を自動化するコードをそのプログラム自身に埋め込み、テストランによってバグの箇所をすぐに特定できるというやり方だったのです。バグを後から見つけるのではなくバグが入り込むのをプログラム作成時に防ぐ、という考え方に私は強い衝撃と感銘を受けました。この本に書かれた「退屈なコードを書こう」というポリシーは、今でも私のプログラミングスタイルの基本になっています。

Kent Beckのテスティング・フレームワークが現れた今となっては内容に古さが感じられますが、根底にある思想の大切さは今でも変わりません。アサーションを使ったことがなくデバッグ情報をprintfで表示させたりしているレベルのC言語プログラマがこの本から学ぶことは多いでしょう。一読をお奨めします。