デバッグ戦略
Strategies for debugging


ポジティブ・シンキング
Positive thinking

自分の想像の中で問題をふくらましてしまう事は良くある事で、 そのせいでそれが数週間、数ヶ月、あるいは数年もかかる仕事に見えてしまいます。 あなたが直面する問題は乗り越えられなさそうに見えるかもしれませんが、 たいていの場合、そうではありません。 以前にもプログラミングをしていたことがあるなら、あなたを絶望のどん底に投げ入れた 同じような出来事を思い出せるでしょう。 しかし思い出して下さい。 あなたはいつもその問題をなんとかして解決したじゃありませんか!
It is common to blow up the problem in one's imagination, so that it seems to threaten weeks, months or even years of work. The problem you face may seem insurmountable: but almost never is. Once you have been programming for some time, you will be able to remember similar incidents that threw you into the depths of despair. But remember, you always solved the problem, somehow!
一見ささいな問題を解決するのに、明らかに過度の時間がかかるとしても、 多くの場合、忍耐は問題解決の鍵となります。 最後にはなぜそんなに心配したのだろうと不思議に思うことでしょう。 しかし、これは手間がかからないということではありません。 心配しないで下さい。 人生にはもっと重要な事がたくさんあります。
Perseverance is often the key, even though a seemingly trivial problem can take an apparently inordinate amount of time to solve. In the end, you will probably wonder why you worried so much. That's not to say it isn't painful at the time. Try not to worry -- there are many more important things in life.

問題を簡単にする
Simplify the problem

問題のコードを、問題を再現できる最小のプログラムになるまで切りつめなさい。 もし大規模で複雑なプログラムを小さなプログラムにする事ができないなら、 あなたのコードがその問題を隠さないようにしなさい (あなたはどうにかして問題を最小限にする努力をしたかもしれません。 しかし、今は問題を表に出したいのです)。
Reduce the code exhibiting the problem to the smallest program possible that exhibits the problem. If it is not possible to reduce a large and complex program to a very small program, then try to ensure your code doesn't hide the problem (you may have attempted to minimize the problem in some way: but now you want to expose it).
運が良ければ、プログラムを機能させなくする少量のコードを追加できます。 これは問題を解決する手がかりを与えるはずです。 しかし、メモリリークや間違ったメモリの解放のような場合には、 完全に誤った結果となる可能性が依然としてあります!
With luck, you can add a small amount of code that causes the program to go from functioning to non-functioning state. This should give a clue to the problem. In some cases though, such as memory leaks or wrong deallocation, this can still give totally spurious results!

デバッガを使う
Use a debugger

これはふざけたアドバイスに聞こえるかもしれませんが、 意外なことに人々はデバッガを使わないことが多いのです。 デバッガのインストールや使い方を学ぶことは多くの場合負担となります。 しかし、非常にささいなプログラム以外には本当に必要不可欠です。
This sounds like facetious advice, but it is surprising how often people don't use a debugger. Often it is an overhead to install or learn how to use a debugger, but it really is essential for anything but the most trivial programs.

ログ関数を使う
Use logging functions

プログラムの中で使用できる様々なログ関数があります: ログ関数 を参照してください。
There is a variety of logging functions that you can use in your program: see Logging functions.
いくつかの状況では、 トレース文はデバッガを使用するより便利かもしれません (デバッガが多くのデバッグコードをサポートしない、変数を出力したいといった場合) 。
Using tracing statements may be more convenient than using the debugger in some circumstances (such as when your debugger doesn't support a lot of debugging code, or you wish to print a bunch of variables).

wxWidgets のデバッグ機能を使う
Use the wxWidgets debugging facilities

メモリリークと不正なメモリをチェックするために wxDebugContext を使用することができます: 実際にデバッグモードでは、 wxWidgets が適切に設定されている場合、wxWidgets は プログラムの終わりにメモリリークを自動的にチェックします。 オペレーティングシステムとコンパイラによりますが、その問題に関する具体的な情報が 多かれ少なかれ記録されるでしょう。
You can use wxDebugContext to check for memory leaks and corrupt memory: in fact in debugging mode, wxWidgets will automatically check for memory leaks at the end of the program if wxWidgets is suitably configured. Depending on the operating system and compiler, more or less specific information about the problem will be logged.
また、問題のテストを行うためにできるだけ早くから wxASSERT を気前よくまき散らし、 '防御的プログラミング' 戦略の一環として デバッグマクロ を使用するべきです。 長い目で見れば、前向きの考え方は驚くほどの時間を節約するでしょう。
You should also use debug macros as part of a 'defensive programming' strategy, scattering wxASSERTs liberally to test for problems in your code as early as possible. Forward thinking will save a surprising amount of time in the long run.
詳しい情報は デバッグの概要 を 参照してください。
See the debugging overview for further information.