わたしがprintf()デバッグをしない理由とか わたしがprintf()デバッグをする理由とかを見て、 私も何か書こうかと思ったんですが、 面倒くさくなってやめてました。 でもちょっとだけ書くことにします。
前にも書いたんですけど、 Ian Lance TaylorのDebuggingというエッセイ を読んでください、でお終いだったりします。 特にここ。
Of course, sometimes a debugger does not help. [省略] In such cases simple print statements can sometimes help locate the source of the bad behaviour. Add print statements to relevant locations, rebuild the program, replicate the problem with the new program, and use the print statements to hone in on exactly what code is being executed when the problem occurs.
まあ、要するに使える方法を使いましょうね、ってこと。 どっちかしか駄目なんてことはありません。 これまた前も書いたことですが、「全か無か」みたいな主張は大体において間違っています。
ちなみに、C前提の話だと、私はほとんどprintfデバッグです。 ソースコード・レベルのデバッガ(gdbとか)が最適化したコードだとまともに追えなくなることが多いので、結局-O0とか付けてコンパイルし直す羽目になる上、そうしたらいきなり問題が起きなくなるという、とてつもなく嫌な現象に何度も出会ってきたもので。
後、TwitterではデバッガのUIの問題とかつぶやいてましたが、それはまあどうでもいいや。 デバッガ使うのはピンポイントできそうな時ぐらい。 そうでないと、大抵余計に時間がかかる気がしますね。
それはともかく、デバッグなんてのは、時間と労力を大量に必要とする作業なんですから、効率のいいデバッグ方法を考えるのも結構なんですが、 その前にバグのないコードを書くことをもっと考えた方がいいでしょう。enbug.orgを持っている私が言うのも何ですが。
現実には私もそれ相応にバグを生産しているわけではありますが、 今まで見てきた他の開発者と比べると、ほとんどの場合、私の方がバグが少ないです。 これは思い切り自慢です。
それには当然コツがあります。 でもケチなので教えてあげません。 冗談です。 本当はどうやったら言葉に出来るか、よくわからないだけです。
一つ確実に言えるのは、いきなり書かないってことでしょうね。 書く前に頭の中に絵を描くことが大事。 その絵がきちんとはまらない、動かないようなら、そんなものはコードにして動くわけないです。 そもそもうまく書けないです。 大抵のバグは、書いた本人でさえ、自信を持ってどうなっているか説明できないような所にあります。
しかしそれでもバグ全然なしってのは無理です。 この前同僚にデバッグにはコツがあるのかと訊かれました。 そのとき、私は「あったらこっちが知りたい」と答えました。 でもデバッグのときも私は大抵の人よりは早いみたいです。 だから自分なりの何かがあるんだと思います。 いくつか例をあげると、
カビ対策をして家の中からカビを除去しましょう。