CodeComplete

[otakumesi]

• [ ] 第1章 ソフトウェアコンストラクションへようこそ
  • [ ] 1.1 ソフトウェアコンストラクションとは
  • [ ] 1.2 なぜソフトウェアコンストラクションは重要か
  • [ ] 1.3 本書の読み方
  • [ ] 1.4 まとめ
• [ ] 第2章 ソフトウェア開発への理解を深めるメタファ
  • [ ] 2.1 メタファの重要性
  • [ ] 2.2 ソフトウェアメタファの使用法
  • [ ] 2.3 一般的なソフトウェアメタファ
  • [ ] 2.4 参考資料
  • [ ] 2.5 まとめ
• [ ] 第3章 2回測って、1度で切る：上流工程の必要性
  • [ ] 3.1 準備の重要性
  • [ ] 3.2 ソフトウェアの種類の特定
  • [ ] 3.3 準備：課題定義
  • [ ] 3.4 準備：要求
  • [ ] 3.5 準備：アーキテクチャ
  • [ ] 3.6 上流工程にかける時間
  • [ ] 3.7 参考資料
  • [ ] 3.8 まとめ
• [x] 第4章 コンストラクションの重要な決断
  • [x] 4.1 プログラミング言語の選択
  • [x] 4.2 プログラミング規約
  • [x] 4.3 テクノロジの波に乗って
  • [x] 4.4 主なコンストラクションプラクティス
  • [x] 4.5 まとめ
• [ ] 第2部 高品質なコードの作成
• [x] 第5章 コンストラクションにおける設計
  • [x] 5.1 設計の難題
  • [x] 5.2 重要な設計概念
  • [x] 5.3 構成要素の設計：ヒューリスティクス
  • [x] 5.4 設計のプラクティス
  • [x] 5.5 一般的な手法へのコメント
  • [x] 5.6 参考資料
  • [x] 5.7 まとめ
• [x] 第6章 クラスの作成
  • [x] 6.1 クラスの基礎：抽象データ型（ADT）
  • [x] 6.2 良いクラスインターフェイス
  • [x] 6.3 設計と実装の問題
  • [x] 6.4 クラスを作成する理由
  • [x] 6.5 言語固有の問題
  • [x] 6.6 クラスを超えて：パッケージ
  • [x] 6.7 参考資料
  • [x] 6.8 まとめ
• [x] 第7章 高品質なルーチン
  • [x] 7.1 ルーチンを作成する理由
  • [x] 7.2 ルーチンレベルでの設計
  • [x] 7.3 良いルーチン名
  • [x] 7.4 ルーチンの長さ
  • [x] 7.5 ルーチンの引数の使用
  • [x] 7.6 関数の使用に関する注意点
  • [x] 7.7 マクロルーチンとインラインルーチン
  • [x] 7.8 まとめ
• [x] 第8章 防御的プログラミング
  • [x] 8.1 無効な入力への防御
  • [x] 8.2 アサーション
  • [x] 8.3 エラー処理テクニック
  • [x] 8.4 例外
  • [x] 8.5 バリケードによるエラーの被害の囲い込み
  • [x] 8.6 デバッグエイド
  • [x] 8.7 製品コードに防御的プログラミングをどれくらい残すか
  • [x] 8.8 防御的プログラミングに対する防御
  • [x] 8.9 参考資料
  • [x] 8.10 まとめ
• [x] 第9章 擬似コードによるプログラミング
  • [x] 9.1 クラスとルーチンの作成手順の概要
  • [x] 9.2 擬似コードプログラミングプロセス（PPP）
  • [x] 9.3 PPPを使ったルーチンの作成
  • [x] 9.4 PPP以外の方法
  • [x] 9.5 まとめ
• [x] 第3部 変数
• [x] 第10章 変数の使用
  • [ ] 10.1 データリテラシー
  • [ ] 10.2 変数宣言のガイドライン
  • [ ] 10.3 変数の初期化のガイドライン
  • [ ] 10.4 スコープ
  • [ ] 10.5 永続性
  • [ ] 10.6 バインディングタイム
  • [ ] 10.7 データ型と制御構造の関係
  • [ ] 10.8 1つの目的に1つの変数
  • [ ] 10.9 まとめ
• [x] 第11章 変数名の力
  • [ ] 11.1 良い名前を選択するために
  • [ ] 11.2 特殊なデータの命名
  • [ ] 11.3 命名規則の力
  • [ ] 11.4 略式の命名規則
  • [ ] 11.5 標準のプレフィックス
  • [ ] 11.6 短くて読みやすい名前の作成
  • [ ] 11.7 避けるべき名前
  • [ ] 11.8 まとめ
• [x] 第12章 基本的なデータ型
  • [ ] 12.1 数値全般
  • [ ] 12.2 整数
  • [ ] 12.3 浮動小数点数
  • [ ] 12.4 文字と文字列
  • [ ] 12.5 ブール変数
  • [ ] 12.6 列挙型
  • [ ] 12.7 名前付き定数
  • [ ] 12.8 配列
  • [ ] 12.9 ユーザー定義型の作成（型のエイリアス）
  • [ ] 12.10 まとめ
• [x] 第13章 特殊なデータ型
  • [ ] 13.1 構造体
  • [ ] 13.2 ポインタ
  • [ ] 13.3 グローバルデータ
  • [ ] 13.4 参考資料
  • [ ] 13.5 まとめ
• [ ] 第4部 ステートメント
• [ ] 第14章 ストレートなコードの構成
  • [ ] 14.1 順序が重要なステートメント
  • [ ] 14.2 順序が重要でないステートメント
  • [ ] 14.3 まとめ
• [ ] 第15章 条件文の使用
  • [ ] 15.1 if文
  • [ ] 15.2 case文
  • [ ] 15.3 まとめ
• [ ] 第16章 ループの制御
  • [ ] 16.1 ループの種類の選択
  • [ ] 16.2 ループの制御
  • [ ] 16.3 ループの作成─ 内から外へ
  • [ ] 16.4 ループと配列の対応付け
  • [ ] 16.5 まとめ
• [ ] 第17章 特殊な制御構造
  • [ ] 17.1 ルーチンからの複数のreturn文
  • [ ] 17.2 再帰
  • [ ] 17.3 goto文
  • [ ] 17.4 特殊な制御構造の展望
  • [ ] 17.5 参考資料
  • [ ] 17.6 まとめ
• [ ] 第18章 テーブル駆動方式
  • [ ] 18.1 テーブル駆動方式の概論
  • [ ] 18.2 直接アクセステーブル
  • [ ] 18.3 インデックスアクセステーブル
  • [ ] 18.4 段階型アクセステーブル
  • [ ] 18.5 テーブル参照のその他の例
  • [ ] 18.6 まとめ
• [ ] 第19章 制御構造の問題
  • [ ] 19.1 論理式
  • [ ] 19.2 複合文（ブロック）
  • [ ] 19.3 null文
  • [ ] 19.4 危険なほど深いネストの回避
  • [ ] 19.5 プログラミングの基礎：構造化プログラミング
  • [ ] 19.6 制御構造と複雑さ
  • [ ] 19.7 まとめ参考文献
• [ ] 第5部 コードの改良
• [ ] 第20章 ソフトウェアの品質
  • [ ] 20.1 ソフトウェアの品質特性
  • [ ] 20.2 ソフトウェアの品質改善技術
  • [ ] 20.3 ソフトウェアの品質改善技術の相対的な効果
  • [ ] 20.4 品質保証はいつ行うか
  • [ ] 20.5 ソフトウェア品質の原則
  • [ ] 20.6 参考資料
  • [ ] 20.7 まとめ
• [ ] 第21章 コラボレーティブコンストラクション
  • [ ] 21.1 コラボレーティブ開発プラクティスの概要
  • [ ] 21.2 ペアプログラミング
  • [ ] 21.3 公式なインスペクション
  • [ ] 21.4 その他のコラボレーティブ開発プラクティス
  • [ ] 21.5 コラボレーティブコンストラクションテクニックの比較
  • [ ] 21.6 参考資料
  • [ ] 21.7 まとめ
• [ ] 第22章 デベロッパーテスト
  • [ ] 22.1 ソフトウェア品質におけるデベロッパーテストの役割
  • [ ] 22.2 デベロッパーテストへの推奨アプローチ
  • [ ] 22.3 テストの知恵袋
  • [ ] 22.4 典型的なエラー
  • [ ] 22.5 テストサポートツール
  • [ ] 22.6 テストの改善
  • [ ] 22.7 テスト記録の保管
  • [ ] 22.8 参考資料
  • [ ] 22.9 まとめ
• [ ] 第23章 デバッグ
  • [ ] 23.1 デバッグの概要
  • [ ] 23.2 欠陥の検出
  • [ ] 23.3 欠陥の修正
  • [ ] 23.4 デバッグの心理学的考察
  • [ ] 23.5 デバッグツール
  • [ ] 23.6 参考資料
  • [ ] 23.7 まとめ
• [ ] 第24章 リファクタリング
  • [ ] 24.1 ソフトウェアの進化の種類
  • [ ] 24.2 リファクタリング概論
  • [ ] 24.3 リファクタリングの詳細
  • [ ] 24.4 安全なリファクタリング
  • [ ] 24.5 リファクタリング戦略
  • [ ] 24.6 参考資料
  • [ ] 24.7 まとめ
• [ ] 第25章 コードチューニング戦略
  • [ ] 25.1 パフォーマンスの概要
  • [ ] 25.2 コードチューニング入門
  • [ ] 25.3 脂肪や糖蜜の類
  • [ ] 25.4 測定
  • [ ] 25.5 繰り返し
  • [ ] 25.6 コードチューニング手法のまとめ
  • [ ] 25.7 参考資料
  • [ ] 25.8 まとめ
• [ ] 第26章 コードチューニングテクニック
  • [ ] 26.1 ロジック
  • [ ] 26.2 ループ
  • [ ] 26.3 データ変換
  • [ ] 26.4 式
  • [ ] 26.5 ルーチン
  • [ ] 26.6 低水準言語への書き換え
  • [ ] 26.7 物事は変わったように見えても、実は変わっていない
  • [ ] 26.8 参考資料
  • [ ] 26.9 まとめ
• [ ] 第6部 システムの考察
• [ ] 第27章 プログラムサイズが及ぼす影響
  • [ ] 27.1 コミュニケーションとチームの人数
  • [ ] 27.2 プロジェクトの規模の範囲
  • [ ] 27.3 プロジェクトの規模がエラーに及ぼす影響
  • [ ] 27.4 プロジェクトの規模が生産性に及ぼす影響
  • [ ] 27.5 プロジェクトの規模が開発作業に及ぼす影響
  • [ ] 27.6 参考資料
  • [ ] 27.7 まとめ
• [ ] 第28章 コンストラクションの管理
  • [ ] 28.1 良いコーディングの奨励
  • [ ] 28.2 構成管理
  • [ ] 28.3 コンストラクションスケジュールの見積もり
  • [ ] 28.4 測定
  • [ ] 28.5 プログラマは人間である
  • [ ] 28.6 管理者の管理
  • [ ] 28.7 参考資料
  • [ ] 28.8 まとめ
• [ ] 第29章 統合
  • [ ] 29.1 統合手法の重要性
  • [ ] 29.2 統合の頻度― フェーズ型とインクリメンタル型
  • [ ] 29.3 インクリメンタル統合戦略
  • [ ] 29.4 デイリービルドとスモークテスト
  • [ ] 29.5 参考資料
  • [ ] 29.6 まとめ
• [ ] 第30章 プログラミングツール
  • [ ] 30.1 設計ツール
  • [ ] 30.2 ソースコードのツール
  • [ ] 30.3 実行可能コードのツール
  • [ ] 30.4 ツール指向の環境
  • [ ] 30.5 独自のプログラミングツールの作成
  • [ ] 30.6 ツールの理想郷
  • [ ] 30.7 参考資料
  • [ ] 30.8 まとめ
• [ ] 第7部 ソフトウェア職人気質とは
• [ ] 第31章 レイアウトとスタイル
  • [ ] 31.1 レイアウトの基本
  • [ ] 31.2 レイアウトテクニック
  • [ ] 31.3 レイアウトスタイル
  • [ ] 31.4 制御構造のレイアウト
  • [ ] 31.5 ステートメントのレイアウト
  • [ ] 31.6 コメントのレイアウト
  • [ ] 31.7 ルーチンのレイアウト
  • [ ] 31.8 クラスのレイアウト
  • [ ] 31.9 参考資料
  • [ ] 31.10 まとめ
• [ ] 第32章 読めばわかるコード
  • [ ] 32.1 外部ドキュメント
  • [ ] 32.2 ドキュメントとしてのプログラミングスタイル
  • [ ] 32.3 コメントを入れるか入れないか
  • [ ] 32.4 効果的なコメントのポイント
  • [ ] 32.5 コメントテクニック
  • [ ] 32.6 IEEE規格
  • [ ] 32.7 参考資料
  • [ ] 32.8 まとめ
• [ ] 第33章 個人の資質
  • [ ] 33.1 個人の資質は話題からずれているか
  • [ ] 33.2 知性と謙虚さ
  • [ ] 33.3 好奇心
  • [ ] 33.4 知的な誠実さ
  • [ ] 33.5 コミュニケーションとコラボレーション
  • [ ] 33.6 創造性と規律
  • [ ] 33.7 怠惰
  • [ ] 33.8 気にするほどのことはない資質
  • [ ] 33.9 習慣
  • [ ] 33.10 参考資料
  • [ ] 33.11 まとめ
• [ ] 第34章 ソフトウェア職人気質とは
  • [ ] 34.1 複雑さの克服
  • [ ] 34.2 プロセスの選択
  • [ ] 34.3 人間が1番、コンピュータは2番
  • [ ] 34.4 言語の中へのプログラミング
  • [ ] 34.5 集中力を助ける規約
  • [ ] 34.6 問題領域に立ったプログラム
  • [ ] 34.7 落石注意
  • [ ] 34.8 反復、その繰り返し
  • [ ] 34.9 汝、ソフトウェアと信仰を結び付けることなかれ
  • [ ] 34.10 まとめ
• [ ] 第35章 さらに情報を得るには
  • [ ] 35.1 ソフトウェアコンストラクションに関する情報
  • [ ] 35.2 コンストラクション以外のトピック
  • [ ] 35.3 定期刊行物
  • [ ] 35.4 ソフトウェア開発者の読書計画

[otakumesi]

クラス = ADT+ 継承 + ポリモーフィズム クラスが持つADTは一つ

[otakumesi]

派生クラスが基底クラスのルーチンを全て呼び出せなければ、継承ではなく包含で実装すべき

[otakumesi]

かつ、そのルーチンから返される返り値は意味的に同じものでなければならない

[otakumesi]

抽象化の基準は、ルーチンを上位に移動した時に上位の抽象化がうまくいかなくなる場合

[otakumesi]

将来の拡張に備えるのだとしたら、できるだけ継承を利用しないこと

[otakumesi]

制御の一元化≒情報隠蔽

[otakumesi]

振る舞いのないデータだけのクラス→他のクラスに属するデータの可能性 データがなく振る舞いだけ→他のクラスに属する振る舞いの可能性（個人的にモジュールやインターフェースにしてmixinが良い？）

[otakumesi]

■ルーチン 引数は入力、変更、出力の順に並べる

[otakumesi]

• エラー処理 堅牢性の高いコードはエラーをアサートしてから処理
• 当たり障りのない値を返す
• 有効なデータでの代用
• 前回と同じ答え
• ファイルに警告メッセージを記録
  • 状態変数
  • 関数の戻り値
  • 例外処理
• エラー処理ルーチン / オブジェクトを使う
• エラーメッセージを表示
• ローカルで最も上手く行く方法でエラー処理
• 処理の中止

堅牢性 vs 正当性の中で非機能要件を見て見極める

[otakumesi]

アーキテクチャのガイドラインがシステムコールのエラーをチェックしないと書いていない限りは、システムコールのたびにエラーコードのチェックをすべき

[otakumesi]

例外はカプセル化を破壊する そのため、本当に例外的状況、すなわち絶対に発生してはならないイベントでのみ使用する それ以外はローカルで処理する ・・・アサーションの使用は絶対に発生すべきではない条件の文書化に限定する。

[otakumesi]

また、例外を投げる場合は抽象化レベル（何をやるのかに対するどんな例外なのかの説明になるような名前をつける）

[otakumesi]

防御雨滴プログラミングはソフトウェアの複雑さを増す危険性もあり、防御的プログラミングのコードにもエラーへの免疫はない。 そのため、どこで防御的になるのかを考える必要がある。

[otakumesi]

入力を受け取る関数と実際に処理を行う関数の間にバリケードを作る関数を設けてエラーによる被害を食い止める。 →エラー処理に配慮する量を減らす。 例：バリデーター

[otakumesi]

バッファオーバーフロー、SQLコマンド、HTML、整数の桁あふれ、悪質な入力に気をつける。

[otakumesi]

PPP…ルーチンの設計手法 →ロジックを言語や環境の文脈を一切入れずに書く ドメインの抽象化レベルに合わせて処理を書く →繰り返し書いて設計を詰める →それらをコードを書くときのコメントにする

[otakumesi]

一般に擬似コードを単純なものになるまで繰り返し検討をする

[otakumesi]

ルーチンが解決する問題を、ルーチンを作成できるくらいに詳細に説明する ルーチンの隠蔽をする情報、入出力、事前条件、事後条件 を準備する

[otakumesi]

変数の寿命はできるだけ短くする

[otakumesi]

デバッグコードやアサーションを利用して、変数に妥当な値が含まれてることを確認する

[otakumesi]

変数に複数の意味を持たせてはいけない。（ハイブリッド結合） 複数の型の意味を持ってしまってわかりづらくなる

[otakumesi]

覚えやすい名前は一般的に解決策ではなく問題を表現している 名前は方法(how)ではなくモノ(what)が良い 問題そのものを表す問題志向で名付けるのが良い

[otakumesi]

避けるべき名前

誤解を招きやすい名前 に通った意味を持つ複数の名前 1、2文字異なるだけの複数の名前 同じような発音 数字を使用する名前 短くするために意図的に綴りを変えた名前 英語で綴りを間違えやすい名前 標準ライブラリのルーチン名や既定の変数名と競合する名前 完全に独断的な名前 読みにくい文字

[otakumesi]

グローバル変数はできる限り使うな その上でどうしても使わなきゃならないときはアクセス用の関数を作って包み込め、直接触るな

グローバル変数の可能性が出てきたとき、それが構造体やクラスで包み込めないかを考える