第1部 バグを作り込まないためのガイドライン

• ガイドライン01　つの変数には1つの役割だけを与える
  • 変数を変身させると，正体を見失う
• ガイドライン02　変数は最小のスコープになるようにする
  • 目の届く範囲が手が届く範囲
• ガイドライン03　変数の初期化は，わかりやすいところで行う
  • 変数やレジスタの初期値は不定
• ガイドライン04　文字列は，可能なら文字配列として扱う
  • char型ポインタはバグの温床
• ガイドライン05　初期化に使う文字リテラルの長さはコンパイラで数える
  • 数え間違えるのは人間．コンパイラは正確に数える
• ガイドライン06　文字列では，最後をつねに意識する
  • 文字列の終わりを示すヌル文字は単なる紳士協定
• ガイドライン07　文字列の長さの表記は統一する
  • ヌル文字の数え方が破綻を引き起こす
• C言語には文字列型はない
• ガイドライン08　ブール型がないC言語では，真偽値の型と値を決めて使う
  • 広く使用する定義はプロジェクトで統一する
• ガイドライン09　モノの種類は列挙型で表現する
  • 同じ種類は同じ枠組みで管理する
• ガイドライン10　ポインタの使用をできるだけ制限する
  • ポインタのバグは大域的に影響する
• ガイドライン11　複雑なポインタの使用はやめる
  • 間接参照が重なると実体を見失う
• ガイドライン12　ビットフィールドが有効なら活用する
  • ビットの操作はコンパイラに任せる
• ガイドライン13　最後のセミコロン（;）をチェックする
  • 終端忘れは後にも響く
• ガイドライン14　複雑さは「()」で補う
  • 暗黙の優先順位を明確にする
• 評価順序について
• ガイドライン15　数値計算では，計算の誤差や演算エラーを考慮する
  • コンピュータは数学のようには計算しない
• ガイドライン16　暗黙の型変換を避ける
  • 密かに行われる型変換を意識させる
• ガイドライン17　望みの型にするには，演算結果ではなくオペランドを

• キャストする
• • 演算結果をキャストしても，手遅れ
• ガイドライン18　浮動小数点の比較は許容範囲を考慮する
  • 浮動小数点数の計算には誤差がつきもの
• 実数を扱うときは誤差にも注意
• ガイドライン19　関数型マクロの予期せぬ展開を避ける
  • 「関数型」であっても，実際は，置換されて展開されるだけ
• ガイドライン20　論理式はできるだけシンプルにする
  • 複雑な条件は，判読/判定が困難になる
• ガイドライン21　0との比較や代入は，数値の0との場合だけにする
  • 0は必ずしも数値の「0」に非ず
• 副作用と副作用完了点
• ガイドライン22　配列インデックスの名前と値に注意する
  • バグは境界やすぐ隣に潜む
• ガイドライン23　ポインタが指している先を確認する
  • 解放した領域は更新されているかもしれない
• ガイドライン24　ポインタの型をつねに意識する
  • ポインタ型の取り違えでアドレス計算は狂う
• ガイドライン25　構造体を扱う演算には，マクロか関数を用意する
  • 構造体は「パッケージ」，バラバラに扱うと意味がない
• ガイドライン26　トップダウンに読めるようにする
  • 秩序のない視点の移動は思考の混乱を招く
• ガイドライン27　関連するものはできるだけまとめる
  • 散在させると注意も散漫になる
• ガイドライン28　分岐やループの処理はブロック化する
  • 制御の及ぶ範囲を明示する
• ガイドライン29　分岐やループの制御部と処理は分離する
  • 制御の仕組みを一目で認識可能
• ガイドライン30　case節では，break文で終わらせるのを基本とする
  • 独立であるべき事象に依存関係を持たせない
• ガイドライン31　else節やdefaultラベル節を省略しない
  • 熟慮した痕跡を記録しておく
• ガイドライン32　適切なループ文を選ぶ
  • 定石を逸脱したループは誤解のもと
• ガイドライン33　ループ管理に関する処理は，先頭か末尾にまとめる
  • 流れに従った記述をすれば，読むのもスムーズ
• ガイドライン34　ループは先頭から入る
  • ループパターンの逸脱はプログラムを脆弱にする
• ガイドライン35　ループからの脱出はわかりやすくする
  • 抜け道は，迷い道
• ガイドライン36　複数のファイルで共有する宣言は1箇所にまとめる
  • プロトタイプの不一致は暗黙の型変換を引き起こす
• ガイドライン37　ヘッダファイルになにもかも詰め込まない
  • ヘッダファイルは実体を作るためのものではない
• ガイドライン38　ヘッダファイルをしっかりと設計する
  • 適切な情報隠蔽で分割コンパイルのメリットを享受する
• ガイドライン39　ヘッダファイルの入れ子は慎重に行う
  • 多重宣言のリスクを回避する
• ガイドライン40　デバッグやテスト用のコードを「出荷」しないようにする
  • 一歩間違えると，品質向上の手段で品質低下
• ガイドライン41　assertを活用し，前提事項を確かめる
  • バグを積極的に炙り出す
• ガイドライン42　コンパイラからのメッセージに耳を傾ける
  • コンパイラの苦言は良薬である

第2部　正しく人が理解するための　ガイドライン

• ガイドライン43　名前を大切にする
  • 名は体を表すべし
• ガイドライン44　違いがはっきりわかる名前にする
  • 識別できるがゆえに「識別子」
• ガイドライン45　名前の付け方に一貫性を持たせる
  • 同じものを違う名前で呼ばない
• ガイドライン46　変数には，実装方法ではなく対象の名前を付ける
  • 知らしめるべきは，「それがなにか」
• ガイドライン47　数字にも意味のある名前を付ける
  • マジックナンバーは情報を隠蔽する
• ガイドライン48　真偽を表すものは，真偽が容易にわかる名前にする
  • なにをもって真とするかが重要
• ガイドライン49　危険の徴候を名前で知らせる
  • 大域的な注意の喚起は目立たせる
• ガイドライン50　関数には役割を表す名前を付ける
  • 「なにをどうする」/「なにを返す」を訴える
• ガイドライン51　読み手に理解しやすい量を意識する
  • 目で追えるから手に負える
• ガイドライン52　1つの行は1つの文にする
  • タテ読み，ヨコ読みが混在すると，誤解/面倒のもと
• ガイドライン53　1行は読みやすい長さにする
  • たいていの環境で収まる長さを心がける
• ガイドライン54　引数の順序を統一する
  • インターフェースのアンマッチを防御する
• ガイドライン55　caseの並べ方には規則性を持たせる
  • 混沌の中に誤りは隠れる
• ガイドライン56　レイアウトでプログラムの構造を可視化する
  • 視覚的な整然さは，すなわち直感的なわかりやすさ
• ガイドライン57　インデントは，確かなものに揃える
  • 不定なインデントはレベルを誤解させる
• ガイドライン58　コードを反復するようなコメントは避ける
  • 自己解説的なコードは無駄なコメントを削減する
• ガイドライン59　他人のためにコメントする
  • コメントは個人的な備忘録に非ず
• ガイドライン60　変更の容易なコメントのスタイルにする
  • 過剰装飾は資源（労力/メモリ）の無駄使い
• ガイドライン61　コメントがコードの邪魔をしないようにする
  • 補う情報で本体を隠さない
• ガイドライン62　定石を逸脱するときはコメントする
  • 読み手の先入観や違和感を払拭する
• ガイドライン63　変数のコメントは，データ宣言の近くに簡潔に書く
  • 遠い注釈は，見逃しと保守漏れの温床
• ガイドライン64　関数のコメントは，関数を使う立場で書く
  • 要旨は見出し．必要最小限に
• ガイドライン65　ファイルのコメントには，モジュールの概要を書く
  • 粒度に応じた要旨にする
• ガイドライン66　「うますぎるプログラム」にしない
  • 超絶技巧よりも単純明解を優先すべき
• コーディングガイドライン チェックツールのポリシー
• ツールの実行環境の構築方法
• ツールの使い方
• ツール一覧
• チェックポイント一覧