少し難しいけど、プログラミングについて学ぶにはいいかもしれません。
もう1年半以上前に読み始めて、途中で理解不能になってあきらめて、でもなんとか読み切りました。
この本は、読み始めた当初から少しレベルが高いなと思っておりまして、そのせいもあって、全部音読してみました。
目で追ってなんとなく読んでしまうよりは、もう少しじっくり内容と向き合った気がします。
とは言っても、やっぱり難しかった。
出会い
この本に出会ったのは、かなり前に紹介した「プログラマー現役続行」がきっかけでした。
この本で著者が推薦されていたので読み始めたわけです。
プログラミング初心者にとって、もしくは独学者にとって、「プログラムとはどうあるべきか？」みたいな根本の考え方を学ぶ機会ってなかなかないですよね。
ともすれば、ネットに転がっているプログラムをコピペして動けばいい、みたいなことになっていたり（かつての私です）。
自分のためにだけ動くプログラムを作るのであれば、そのくらいの気持ちでプログラミングを始めるのはすごくいいと思いますが、もう少しプログラミングに関わりたくなってくると、この種の本が必要になります。
この「プログラミング作法」では、VBAのことを解説しているわけではありませんし、Wordについて書かれているわけでもありません。
主にC、C++、Javaが登場しているようです。
でも、インデントを入れる意味、コメントの書き方、変数の名称のつけ方、デバッグの方法など、特定のプログラミング言語に限定されない考え方を学ぶことができます。
あと、こんなものどうですか？デバッグの項目の一部を抜粋します（P.172)。
打つ前に読め。 効果的なわりに過小評価されているデバッグテクニックのひとつに、「コードを舐めるように読んで、変更を施さずにしばらくよく考えてみること」がある。た しかに、すぐにでもキーボードに手を伸ばしてプログラムを修正し、それによってバグが消えてなくなるかどうかをためしてみたくてたまらなくなると思う。し かしそれだと本当の原因がわからないまま見当違いの変更を施してしまうのが関の山で、別の部分をだいなしにする可能性もある。
ドキッとします（笑）。
ただ、よくわかります。
短いプログラムはコンピューターにデバッグさせてしまうことがありますが、長いプログラムの場合は印刷をして読み返すとエラーを発見しやすくなります。
私にとっては印刷をして読み直すと発見しやすいという点は、翻訳の見直しを印刷をして行うことと同じです。
第1章はスタイルについてです。コメントの書き方など説明されていますが、この章が一番わかりやすくてワクワクしてきました。
それ以外の章では、時々参考に使える考え方に出会いましたが、途中難しかったですね。。。
というわけで、骨太の本ですが、刺激がほしい方どうぞ。