プログラムが思い通りに動かない。これは失敗ではなく、通常運転です。プロでも1日に何度も起こります。違うのは、その後の動き方です。
バグとは何か
バグとは、プログラムが期待と違う動きをすることです。ここで一つ、大事な確認を。
プログラムは、あなたが思った通りには動きません。書いた通りに動きます。
つまりバグがあるとき、機械は正常です。ずれているのは、頭の中の想定と、実際に書いた文字のほうです。これをデバッグ（虫取り）と呼びます。
師範「なぜ動かん」と嘆く前に、「何が起きておるか」を見よ。順序を逆にする者が多い。
やってはいけないこと
まず、やりがちな失敗から。
- あちこち適当に書き換える — 直ったとしても理由が分からず、また起きる
- 一度に2か所以上直す — どちらが効いたのか永遠に分からない
- エラーを読まずに検索する — 目の前に答えが書いてあることが多い
正しい手順は4つ
- 現象を正確につかむ — 「動かない」ではなく「入力に5を入れると、10と出るべきところが0と出る」。ここが曖昧なままだと、この先の全部が曖昧になります
- 確実に再現させる — 毎回同じ操作で同じ結果が出ることを確認する。再現できないバグは直せません
- 範囲を狭める — ここが本題です（次で説明）
- 仮説を1つ立て、1つだけ変えて確かめる — 予想と結果を必ずセットで記録する
範囲を狭めるは、二分探索でやる
前のトラックで学んだ「半分に割る」がここで効きます。
プログラムの真ん中あたりで、変数の値を表示させてみます。そこまで正しければ、バグは後半にあります。おかしければ前半です。これを繰り返せば、100行のプログラムでも7回ほどで原因の行にたどり着きます。
トレース表と組み合わせる
狭められたら、その範囲を紙の上でトレースします。そして、実際の実行結果と突き合わせます。
- 紙の上の値と実際が同じ → その範囲は正しい。想定のほうが間違っている
- 紙の上と実際が違う → 最初に食い違った行が犯人
この「最初に食い違った行」を見つけたら、勝ちです。第3トラックでトレース表を練習してきたのは、この瞬間のためだと言ってもいいくらいです。
バグには3つの種類がある
種類が分かると、探し方も決まります。
- 文法の誤り — コンパイラが場所を教えてくれる。いちばん楽
- 実行時の誤り — 動くが途中で異常終了する。0で割った、無いものを触った等
- 論理の誤り — 最後まで動くのに答えが違う。いちばん厄介
3つ目には、機械は何も言ってくれません。だからトレース表が要るのです。「動いているのに間違っている」を見つけられる道具は、今のところ人間の目と表しかありません。
記録を残す
試したことと結果は、必ずメモしてください。「これを試した→変わらなかった」の積み重ねが、犯人を追い詰めます。記録がないと、同じことを3回試して、3回とも気づかない、という事態が普通に起こります。