プログラミング作法　

「プログラミング作法」　(THE PRACTICE OF PROGRAMMING)

ブライアン・Ｗ・カーニハン
ロブ・パイク
福崎俊博訳
ASCII刊

　初級〜中級のプログラマな方、とくに仕事にされている方には、 ぜひ手元に置いて読んでもらいたい一冊です。

　プログラミングをする上で、ソフトウェア開発に従事する上で、 知っておくべきこと気にすべきこと （スタイル,アルゴリズムとデータ構造,設計と実装,デバッグ,性能,など）の 捉え方考え方や配慮の仕方のような ノウハウ(の初歩的/基本的なこと)がたっぷり詰まっています。

　最初は？が多くても、ざっとでも見ておき、後の経験で わかってくることもあるでしょう。 知っていることばかりだ、と言える人にとっても、 まとまっている本があるのは便利ですし、 経験あるプログラマならば自分との差異を確かめてみるもよいかもしれません。

　カーニハンには、邦訳で 「プログラム書法」という、 旧FORTRANを題材にした本書と同様の本がありますが、 今回のものは C/C++/java系の言語をメインに据えて、内容も バージョンアップしたようなものになっています。

　他にもカーニハンには他にも「ソフトウェア作法」(Software Tools)という 名著もありますが、それはまた別の趣旨の本で、これらの邦題だけを見ると ちょっと紛らわしい状態のようです（うろ覚えで買おうとすると特に^^;・・・ こちらの本は 原題の"ソフトウェア・ツールズ"という道具としてのプログラミングの考え方や ノウハウといったもので、いい本ですが、ratforという ちょっと違う言語を用いていて解説されているので、多少面倒くさい面があるかも）。

　以下に、目次を抜き出して見ます。このタイトル自体が、 プログラマとして気にすべきことの一覧となっているといえるでしょう。

• スタイル　　 名前, 式と文, 一貫性と慣用句, 関数マクロ, マジックナンバー, コメント, なぜ手間をかけるのか
• アルゴリズムとデータ構造　　 探索, ソーティング, ライブラリ, クイックソート, O記法, 配列の伸張, リスト, ツリー, ハッシュテーブル
• 設計と実装　　 マルコフ連鎖アルゴリズム, データ構造の選択, Cによるデータ構造の作成, 出力の整形, Java, C++, AwkとPerl, 性能
• インターフェース　 カンマ区切り値, プロトタイプライブラリ, 他人の使うライブラリ, C++による実装, インターフェースの原則, リソース管理, 中止しますか再試行しますか失敗させますか？, ユーザーインターフェース
• デバッグ　　 デバッガ, 有効な手がかりのある簡単なバグ, 手がかりのない困難なバグ, 最後の手段, 再現不能のバグ, デバッグツール, 他人のバグ
• テスト　　 コーディング時のテスト, 系統的なテスト, テストの自動化, テスト機構, ストレステスト, テストのコツ, 誰がテストを担当するのか？, マルコフプログラムのテスト
• 性能　　 ボトルネック, 時間計測とプロファイリング, 高速化の戦略, コードのチューニング, メモリ効率, 性能の見積もり
• 移植性　　 言語, ヘッダとライブラリ, プログラムの構成, 隔離, データ交換, バイト順, 移植性とバージョンアップ, 国際化
• 記述　　 データの書式化, 正規表現, プログラマブルツール, インタープリタ・コンパイラ・仮想マシン, プログラムを記述するプログラム, マクロによるコード生成, オンザフライコンパイル
• エピローグ　
• Appendix ルール集　

「ルール集」

　巻末の、ルール集を抜き出してみました （己にとっては手で読んだ残骸とも^^;）。 これだけでも何かの足しになるかもだけど、 ある意味これも目次みたいなもんなので 詳しくは書籍にあたったほうがよいでしょう。

スタイル:名前

• グローバルにはわかりやすい名前を、ローカルには短い名前を
• 統一しよう
• 関数には能動的な名前を
• 名前は的確に

スタイル:式と文

• 構造がわかるようにインデントをしよう
• 自然な形の式を使おう
• かっこを使ってあいまいさを解消しよう
• 複雑な式は分割しよう
• 明快に書こう
• 副作用に注意

スタイル:一貫性と慣用句

• インデントとブレースのスタイルを統一しよう
• 慣用句によって一貫性を確保しよう
• 他分岐の判定には else-if を使おう

スタイル:関数マクロ

• 関数マクロはなるべく使うな
• マクロの本体と引数はかっこに入れよう

スタイル:マジックナンバー

• マジックナンバーには名前をつけよう
• 数値はマクロでなく定数名として定義しよう
• 数値でなく文字定数を使おう
• オブジェクトサイズは言語に計算させよう

スタイル:コメント

• 当たり前のことをいちいち書くな
• 関数とグローバルデータにコメントを
• 悪いコードにコメントをつけるな、書き直せ
• コードと矛盾させるな
• あくまでも明快に、混乱を招くな

インターフェース

• 実装の詳細を隠蔽しよう
• 直交性のある小さなプリミティブセットを選択しよう
• ユーザーに内緒で何かをするな
• 同じことはどこでも同じように実行しよう
• リソースの開放は割り当てと同じレイヤで
• エラーの検出は低いレベルで、その処理は高いレベルで
• 例外は例外的な状況にのみ使用しよう

デバッグ

• おなじみのパターンを見つけよう
• 最新の変更点は要チェック
• 同じ間違いを繰り返すな
• デバッグは今すぐに
• スタックトレースを取得しよう
• 打つ前に読め
• 自分のコードを他人に説明してみよう
• バグを再現できるようにしよう
• 分割統治しよう
• 誤動作を「数字占い」で検証しよう
• 出力表示によってバグ探索範囲を狭めよう
• 自己検証コードを記述しよう
• ログファイルを出力しよう
• 作図しよう
• ツールを使おう
• 記録をとろう

テスト

• 境界をテストしよう
• 事前と事後の状態をテストしよう
• アサーションを使おう
• プログラミングは防御的に
• エラーの戻り値をチェックしよう
• テストはインクリメンタルに
• テストは単純な部品から
• 期待される出力を把握しておこう
• 保存される性質を検証しよう
• 独立した実装同士を比較しよう
• テストの網羅範囲を測定しよう
• 回帰テストを自動化しよう
• 自給自足テストを作成しよう

性能

• 時間計測を自動化しよう
• プロファイラを利用しよう
• ホットスポットに神経を集中しよう
• 作図しよう
• より優れたアルゴリズムやデータ構造を利用しよう
• コンパイラの最適化を有効に
• コードをチューニングしよう
• 関係ない部分を最適化するな
• 共通する式をまとめよう
• 高価な処理を案化な処理に置き換えよう
• ループは展開するか除去しよう
• 頻繁に使われる値をキャッシュしよう
• 専用のアロケータを書こう
• 入力と出力をバッファリングしよう
• 特別なケースは別個に処理しよう
• 結果を事前に計算しておこう
• 近似値を使おう
• より低級な言語で書き直そう
• できる限り小さなデータ型を使って領域を節約しよう
• 簡単に再計算できるものを記憶するな

移植性

• 標準に固執しよう
• 王道のプログラミングをしよう
• 言語のトラブルスポットに気をつけよう
• 複数のコンパイラで試してみよう
• 標準ライブラリを使おう
• どこでも利用できる機能だけ使おう
• 条件コンパイルは避けよう
• システム依存のコードは別個のファイルに
• システム依存部分はインターフェースの裏に隠蔽しよう
• データ交換にはテキストを
• データ交換には固定のバイト順を使おう
• 仕様を変えるなら名前を変えよう
• 既存のプログラムやデータとの互換性を維持しよう
• ASCIIを前提にするな
• 英語を前提にするな