[1996/01/30]
プログラムデバッグ心得 (debug rule)
------------------------------------------------------
0. 揺さぶりをかける
------------------------------------------------------
a. 考える
-- 何をしたいのかを考える（目的）
-- 何をすればいいのかを考える（方法）
-- どうなればいいのかを考える（目標）
b. 気力を保つ
c. 休憩する
d. うっかりミスを防ぐ
e. プログラムリストを印刷してみる
------------------------------------------------------
1.1 問題を簡単にする．整理し分割する
-- 必要のない変数を削除する
-- 長い関数を切り分ける
切り分けられない場合は問題が整理されてない
-- 関数への引数を最小限にする
長くなる場合は問題が整理されてないかも
-- 似た用途の変数が多数存在する
構造体でまとめる
-- マイナーチェンジの部分が多数存在する
単一の機能を持つ関数を利用する？
-- 変更点を一つにまとめる
ヘッダファイルの使用
定数・ マクロの定義
（マジックナンバーを使わない）
-- でも問題を簡単にするのも難しいのだ！
--> どうしても複数の事をまとめてやってしまおうとしてしまうなぁ
（特に時間のないときは．．．(--")）
--> 問題を各要素に分離できる能力が必要なのか？
-- c.f. 初心者のプログラムの関数はめちゃめちゃ長くなる．
1.2 段階的に処理する
1.3 部分的に確実にする．動作確認を行う．
------------------------------------------------------
3. 装置のケーブル接続確認
-- つながってるか？
-- スイッチは入ってるか？
-- 壊れてないか？
------------------------------------------------------
4. 変数の初期化の確認（超基本！！）
-- 初期化がちゃんとしてなかったら，まともに動く筈がない
-- 繰り返し処理や総和を求めるとき
-- 変数の型のチェック
-- 配列のサイズや領域確保・開放
-- 何がなんでも初期化を行う（<-- 処理時間との相反関係）
-- 元データのチェック
処理結果がおかしいのではなく元データの段階で
壊れているのではないか？
5. 境界値（0 とか最大値とか）での処理結果の確認
-- 結果の予測の容易な値を使ってみる
-- １増やす
-- １減らす
-- 倍にする
-- 半分にする
6. 値を変えてみる
効果がなかったら異常
7. バグを故意に起こしてみる
そのバグが起こらなかったら異常
8. 処理をやめてみる
その処理の効果が残っていたら異常
9. 処理順序を変えてみる
順序に関係ないはずなのに結果が変わったら異常
10. 処理量を減らしてみる
簡単に把握できる量でデバックする
ゆっくり処理してみる
------------------------------------------------------
96. 別の言語を使ってみる
97. 別のコンパイラを使ってみる
98. コンパイルしなおしてみる
99. イチから作り直してみる
参考文献:
「プログラム書法」
「プログラム作法」
「プログラミングのエッセンス」
追記:[1996/02/06]
[1997/12/28]
| 
プログラムデバッグ心得