kawasin73
commented
6 years ago 要約
１章と２章はメモを取るのを忘れた。 ただ、あまり驚くことは書いてなかったと思う。
この本で紹介されていることは言語には依存しないが、全体としてC言語をベースに書かれており、他の言語での考え方も触れられている。
1章 スタイル
2章 アルゴリズムとデータ構造
3章 設計と実装
- データ構造を決めればあとのアルゴリズムはおのずと決定する
- 使えるかもしれないアルゴリズムを念頭に置きながら、データ構造を詳細に設計することから始めるのがベスト
4章 インターフェース
- 設計において解決すべき代表的な課題
- インターフェース
- 情報の隠蔽
- リソース管理
- エラー処理
- プロダクションコードに紛れ込んだ一時しのぎのコードは汚いまま案外長く運用される
- ユーザーインターフェイス
- 簡潔性、明瞭性、整合性、均一性、日常性、慎み深さ
5章 デバッグ
- バグを再現する
- バグの周期性に注目する
- print デバッグの重要性
- assert を入れて落とす
- ポインターによるバグは予測不能な影響を及ぼす
6章 テスト
- 間違いを短時間で効率よく効果的に発見するテスト方法
- プログラムを自動生成するとバグを抑えることができる
- コーディングをしながらテストも並行して書く
- 条件分岐や、引数などの境界条件テスト
- 事前状態と事後状態のテスト
- assert を使う
- 防御的プログラミング
- エラーのチェックをする
- 系統立ててテストケースを列挙する
- 小さい単位でテストして積み上げる
- テスト手順の自動化
- 出力結果を期待される出力と比較する
- 独立した実装同士の出力を比較する
- カバレッジの測定
- テストの自動化
- テスト機構
- 正しい結果と比較する。正しい結果はパフォーマンスに問題があるが正しい結果をだす前のバージョンを用いて作成する。段階的なアプローチ
- ストレステスト
- 機械的にランダムに入力を生成しあり得ないケースを引き起こすことが目的
- バッファオーバーフローエラー。想定より長い入力で別の部分のメモリをうわがきする。入力の長さを制限する必要がある
- テスト時にはあえて失敗するような出力を返すモックを作成して利用する
- 初期化忘れを発見しやすくするため、初期値を
0xDEADBEEFにすることも - 複雑な挙動をするプログラムのテスト
- 境界条件を確かめる小さな条件から
- テストをなるべくシンプルに
- 出力そのものを生成するのではなく、出力の特性を検証する
- ランダムな出力の場合は、出力の頻度のテストを行う
7章 性能
- 性能改善前のシンプルなバージョンを評価の基準として残しておくこと。
- サブルーチンの集まりを最適化して、無駄な部分を省く
- 正しい問いを立てる。そもそもの課題に立ち返る
- 最適なアルゴリズムを使用する
- ボトルネックの箇所をプロファイリングその他のテクニックを駆使して調査する
- 局所最適化ではなく、プログラム全体を検証
- プロファイリングによって極端に時間を使う関数の特定
- 優れたアルゴリズムで改善
- 関数呼び出しを取り除く
- コンパイラの最適化オプション
- デフォルトではデバッガが正しく動くように最適化されない
- チューニングをする
- 効果があるかどうかは計測をしないとわからない
- 関係ない部分を最適化しない
- 共通する式をまとめて値を再利用する
- 高価な処理を安価な処理に置き換える
- ループアンローリング
- キャッシュの利用（キャッシュは外部から見えないようにする）
- バッファリング、事前計算、近似値の利用
- 低級な言語での書き直し：最後の手段：低速でも正しいポータブルな実装を作って参考にする
- メモリ効率
- 基本は気にしなくて良い。
- 小さなデータ型をつかう
- 簡単に計算できるものを保存しない
8章 移植性
- 移植性のあるプログラムは大抵優れたプログラムである
- 準拠しなければならない各種の標準やインターフェイスや環境に共通する条件の枠内で動作するように心がける
- 結び（システム依存の実装を
#ifdefで積み重ねる）と交わり（標準のみで実装する） - 移植性のないコードを使うときは、抽象化とカプセル化によって依存部分を局所化する
- 完全に厳密な定義のある言語はない。未定義の部分があることによって効率の良いコンパイラが実装される余地が生まれる
- 言語の定義にあいまいさがなく、十分に理解されている機能だけを使う
- C言語では int や char などの最低ビット数は決まっているが具体的なサイズはコンパイラ依存
- C言語ではオペランドの評価順は未定義
- char は符号の有無が定義されていない。
getchar()はintで受けるべき
- 移植性を求めるなら、複数のOS で複数のコンパイラでコンパイルして警告がでないことを確認する
- 標準に固執する
- どこでも使える機能を使う。使えない場合を想定してパッケージに入れておく
#ifdefを使うと構文チェックされない。if (DEBUG)すると構文チェックされた上で、コンパイラが削除する。条件コンパイルをなるべく使わない- システム依存の部分は抽象化してインターフェイスの裏に隠蔽する
- テキストを使う。CRLFは気をつける
- バイナリプロトコルでは、エンディアンを決めておく。パッキングとアンパッキングは8ビットずつ行うことで移植性が生まれる
- 互換性が無くなるときは名前を変える
- 国際化
- Unicode はバイト順を混乱させないために UTF-8 というバイトストリームエンコーディングに変換される
9章 記法
- 目的に応じて適した記法がある。複数の言語をあつかえるようにするとよい。適切な言語がない場合は自作するのもよし（例：printf）
- 反復的なコードが現れる→記法を応用するヒント
- コンパイラ
- 織り糸コード：再帰呼び出しについて呼び出しスタックを完全にフラットに展開する
- オペランドを関数テーブルのインデックスにして、処理する関数を検索すると、コードがシンプルになる
- 文芸的プログラミング：特別なコメントに意味を持たせる
- JIT
- 必要になる処理を実行時に生成（コンパイル）して、全てのパターンを網羅した処理を事前にコンパイルする手間と領域を減らす
プログラミング作法
https://www.amazon.co.jp/プログラミング作法-ブライアン-カーニハン/dp/4756136494
https://www.amazon.co.jp/プログラミング作法-Brian-W-Kernighan/dp/4048930524