タイトル
プログラミング作法
著者
ブライアン カーニハン (著), ロブ パイク (著), Brian Kernighan (原著), Rob Pike (原著), 福崎 俊博 (翻訳)
出版社
アスキー
Amazonで購入する

この世の中に、自分のソースコードを芸術のように扱うプログラマーがいったい何人いるのだろうか。本書を読み終わった後、プログラミングって芸術だよなーって、一人で納得してしまいました。

ソースコードは、コンピュータが解釈するもの。良いソースコードは、人が解釈できるもの。自らのプログラミングソースを優れたものとして自慢できるプログラマーに僕はなりたい。本書はそんな願いをかなえてくれる、すばらしきバイブルです。

特徴

本書は、以下のような経験をしたことがあるプログラマーに是非とも読んでいただきたい。

  • 間違ったアルゴリズムでコーディングしてやたらと時間を無駄にした
  • 使用するデータ構造が死ぬほど複雑になった
  • プログラムをテストしたのに明白な問題点を見落としていた
  • 5分もあれば見つかるはずのバグを1日がかりで探し回った
  • プログラムを3倍速くしメモリ使用量も減らしたいと思った
  • ワークステーションとPCの間でプログラムを移植するのに苦労した
  • 他人のプログラムに少々変更を加えようとした
  • さっぱり理解できないプログラムを書き直した

基本的で互いに関連しあう原則

  • 簡潔性(simplicity)
  • 明瞭製(clarity)
  • 一般性(generality)
  • 自動化(automation)

この4つの原則を基本アプローチとして解説している。

本書の目次は以下のようになっている

  • スタイル
  • アルゴリズムとデータ構造
  • 設計と実装
  • インターフェース
  • デバッグ
  • テスト
  • 性能
  • 移植性
  • 記法

本書の例は、C言語もしくはそれに似た言語で書かれている。しかし、作法という点で見るとどの言語についても言える、高水準なものが説明されている。

本書の中で特に良かったと思うところを参考までにあげておきます。

スタイル

よいコーディングとはどのようなものかを解説しています。具体的なコード例が載っていて、なぜこれが良いのかという理由がはっきりしているのが魅力的です。

名前についても書かれています。変数名やメソッド名、インターフェース名やクラス名にはどのような名前をつけたらよいのかも解説しています。名前は、情報を含み、簡潔で覚えやすくできれば発音可能な名前にしなければならない。

他にも、聞きたくても聞けなかった疑問や、使えるTipsなど豊富に盛り込まれています。例えば、「オブジェクトサイズは言語に計算させよう」や「悪いコードにコメントはいらない。書き直せ。」など、プログラマの聖書となるようなアドバイスがたくさんです。

インターフェース

設計においてまず解決しなければならない問題をしっかりとした理由をつけて解説してくれています。インターフェース設計で注意する点やライブラリを作るときの心構えなども載っています。

「インターフェースというのは要するに提供者と顧客の間の契約だ」「ペアとなる作業(リソースのオープンとクローズなど)は同一のレベルないし同じ場所で実行されるべきだ」「原則として、ライブラリルーチンはエラー発生時に単純に死んではならない」「ユーザに内緒で何かをするな」など、目からウロコが落ちるアドバイスばかりです。

デバッグ

「丁寧な治療よりもほんのちょっとした予防のほうが、現実にはるかに効き目がある」「プログラムをステップ実行するよりも、もっと真剣に考えたり、重要部分に出力分野自動チェックコードを追加したりするほうが効率的」「コードをなめるように読んで、変更を施さずにしばらくよく考えてみること」

デバッグするときの金言集になっています。

本書について説明すればするほど、本書の価値が下がってしまうような気がします。ほんとうに良いものに、説明は必要ない。そんな言葉が一番マッチする本だと思います。

参考

  • C言語の処方箋

Cプログラミング診断室

  • 本書を実践している人たちがずばりこの人たちでしょう。

  • アルゴリズムに特化した、超おすすめ本