Creative Debugging

[marwex89]

CREATIVE DEBUGGING

By marwex89 on CodeCall forum
The term (not method) "Creative debugging" was invented by me, as far as I know.


Haven't we all scratched our head sometimes, wondering what on earth (or in cyberspace) went wrong? In the process of programming, debugging usually takes more time that we would like it to, and can be a real pain, especially in large and complex projects. In this short tutorial, I will try to share a few debugging tricks and tips with you, to make debugging easier, and perhaps more fun.

THE BASICS

ERRORS ("BUGS")

As most programmers know, we basically have three types of errors:
1. Compiler/linker errors (e.g. "Error: Variable not defined", program won't even execute)
2. Runtime errors (e.g. "Error: Buffer overflow" each time you press that button)
3. Program behaviour errors (e.g. "Why does it display "Cat", not "Dog"??" when I... etc)

Compiler/linker errors are the easiest one to debug, as the compiler will often give you a decent clue about where and what the problem is. A quick google-search usually solves this one.

Therefore, this tutorial will focus mainly on the second, runtime errors, and the third type, program behaviour errors. These occur when you are able to execute you program, but it does not behave the way you wanted it to. These errors can be extremely difficult to find, especially those of the third type, and may require weeks and months of debugging to solve.

THE BUILT-IN DEBUGGER

There are several ways to debug your code. The most obvious might be the built-in debugger your IDE is providing. Of course, not all IDEs have this option, and if you are using Notepad, you will (most likely) waste your time searching for a "Debug" menu. Quite a few compilers come with tools for debugging your code, and many IDEs do little more than actually packing these into a user friendly environment, which means that even a Notepad user will have access to them, at least in theory.

Using the built-in debugger usually means setting breakpoints in your code, slowly stepping through the program, watching variable values as they change, and similar basic debugging steps. These can be extremely useful, for all error types. Unfortunately, describing use of external debuggers is beyond the scope of this tutorial, and is also more or less language specific.

Sometimes, like when you are programming HTML with Notepad, the luxury of a "debugger" is not present, which leads us to the interesting topic: Creative debugging.

ADVANCED DEBUGGING

CREATIVE DEBUGGING

If there are two things programmers tend to ignore when starting a project, it must be debugging and error handling. If these things are not implemented in your code from the beginning, you are making things a lot harder for yourself, trust me. Make your own error and debugging classes, if possible, and make sure you use them.

Those of you playing computer games might have noticed that some of your games has a built-in "console", similar to "cmd.exe" in Windows. This is a great example of creative debugging. The "console" basically lets an advanced user modify the variables, constants and settings at runtime, while playing the game. This means that you can debug in fullscreen, realtime, and most important for non-game developers: At the client's/user's computer. This can be extremely useful in many situations.

IMPLEMENTING CREATIVE DEBUGGING IN YOUR CODE

Start out with declaring a global/public variable, inside your own debug class or not, and name it e.g. "developerMode". Congratulations! You have just started creative debugging!

Think of this variable as a boolean. It can be "true", or "false" (or "on and "off", "1" or "0"). If it is "false" (off), your program will act like normal. This is the "userMode", so to speak. If its value is "true", however, things are getting interesting. Notice that you could also make this variable an integer, having multiple levels (or "modes"). In one of my recent projects, we used 3 modes: "Ordinary user", "Privileged user" and "Technical user", the last one being "developer mode".

When your program is running in "developer mode", you should provide the user, or developer, with thorough information about what is going on under the hood of your program. This can be done in various ways, like the "console" mentioned earlier, and is mostly limited by your imagination, IQ and programming skills. Doing this well will make it much easier to solve errors of the 3rd type, "program behaviour errors".

There is one more question, though: When do we activate developer mode? This is totally up to you, but there are some common solutions to this.

1. Using command line options (e.g. -dev)
2. Key combination (user pressing a specific key combination)

I strongly recommend the last solution, as this can be turned on/off without restarting your program. This is also the most common solution for games (activate/deactivate "console").

TEMPORARY OR PERMANENT?

You will need to decide which modifications/monitoring options should be temporary (just to fix that error) and which should be permanent (for later support). With your own, good, creative debugging system, it should be easy to throw in some logging/monitoring/modifying options on a variable in source code when you need it, but when the error is solved and your code is tested, feel free to remove unnecessary debugging in your code, preferably by "commenting them out" so that you can easily access them for your new version of the program. Don't be naive, it will contain errors.

LOG FILES

Developer mode or not, you should consider making a simple, or encrypted, log. This can be used for support issues when your program has been distributed, and for debugging when your program is being developed. Very useful, especially in those cases where your program hits a wall and terminates without warnings. No time for variable monitoring then. Remember: Debugging and error handling are brothers. Do not emphasize one without knowing what you are doing. Do both, and do them well.

FINALLY

Please forgive me for not having covered all aspects of this subject. If anything is unclear, or you have questions, send me a message or post a comment on CodeCall (usually fast reply) or by email (expect slow reply...) mw_ex[AT]hotmail.com (replace [AT] with @).

Just being aware of these things will help!

Good luck with your programming!

DISCLAIMER:
The author of this text is not responsible for any hysterical reactions readers might have after reading this text. And sorry for any bad english.

[MeTh0Dz]

You could just use OutputDebugString() and the DebugView application.

[marwex89]

That's not creative, but OK

[Jordan]

Good information, +rep.

[Egz0N]

Good One .. +rep

[Xav]

Why did you post your email address?

[marwex89]

Because I often do when writing stuff like this

[Xav]

Even though you will get spammed to hell?

[marwex89]

Haven't been yet, but if I do, I'll let you know ("What did I say.....")

[Xav]

I would strongly advise not posting your email address. You never know when a bot is crawling around..