Best bugfixing/errorfinding strategy - all languages

Question

Hi!

I found out, while shoulder surfing some other - much more experienced programmers - that they all have different strategies in finding (their) errors in (their) code.

And I don't mean understanding compiler error messages, but understanding the reason why the error message occurs - immediately by following the code-flow and locating a semantical error. That sounds almost too easy.

The problem is: stuff tends to grow huge. I can't follow all my 3000 lines of code and keep everything in mind including auto-generated code for GUIs. Even if I separate pieces, it's still too much to begin again and re-read everything.

I just wonder what the most common practices are to make stuff work :). What do you do if you don't understand why the compiler throws error messages?

Answer 1

Compiler errors are not bugs, they are your friends. The moment all programmers dread is when their code compiles and links without errors and they have to actually run the damn thing. That's when the bugs start to appear.

Compiler errors specify the actual line that the error occurs on (plus or minus one, typically). They do this by analysing syntax, they do NOT analyse "code-flow"or semantics. Your task as a programmer is to correct the syntax; the bugs live in the semantics, which can only be investigated when the program has been compiled and is being run.

Answer 2

If you don't understand why the compiler is throwing error messages, you'll need to copy the messages into the stackoverflow or Google search boxes. With some notable exceptions, the compiler is our friend...I think...

Answer 3

My best strategy is to have multiple strategies. That said, my best strategies are:

• Assume nothing. Anything you are sure of beyond doubt is a rock for bugs to hide under. If you never turn the rocks over, you'll never find the bugs.
• Form hypotheses and test them. By test them I mean specifically come up with an experiment you can perform which will show one result if (and only if) your hypothesis is correct. and something different if it is wrong.
• Once every few years spend a weekend watching old Colombo episodes.
• Don't get suckered in by comments; only trust the code.
• Take baby steps. Biting off more than you can chew just means you'll choke.
• Define the problem till it has a razor sharp point on it. Many times, that will give you the solution right of the bat. In any case, you stand little chance of solving a problem you can't define.
• Make sure you can reproduce the problem. Find the simplest case that will reproduce it.
• Find the closest case to you simplest failure case that works.
• Log data that will answer questions, not just fill up space.

Answer 4

Separate your code into small meaningful parts.

The key is the meaningful, you should be able to remember what a part does without reading through its code again.