The Art of Code Debugging, How to Properly Debug Your Code

Posted on April 1, 2016 By

Code DebuggingAs a lot of criteria would differ a newbie programmer from an experienced and skillful one, one of the most important criteria is the ability to debug their own code.

A beginner programmer would write his code snippet, leave parts “for later”, without spotting the fact that they left a bunch of bugs, compile and run the code, and then see that his code doesn’t work, for some weird reason. Well, starting from the compilation part to noticing that everything is screwed up is a part of programming itself, and bugs on the first compilation doesn’t make you a bad programmer.

But the difference between bad/inexperienced programmers and skillful/experienced programmers starts here. Most of the “programmers” out there would think about their problem for (maximum) 5-10 minutes, then go to StackOverflow/FXP/Their senior programmer friend, and post something like that:

Hello.

My code doesn’t work. Here it is:

<some code>

Please fix it to me.

If you can’t spot at least 3 wrong things about this post, well, you should start thinking about a new career. This post shows a typical “I have never really tried to solve this problem, solve it for me” way of thinking. You can immediately see that:

  1. “My code doesn’t work” – Well, OK there. If it worked, you wouldn’t have posted it here, right? What really doesn’t work? Do you expect your friends to understand your code by themselves?
  2. “Please fix it to me” – This shows zero will to really solve the problem. You have to understand that as long as the problem is yours, you are the one who should solve it.

And of course, I must mention that asking other people/your smarter/more experienced friend should be the LAST thing you do. First, you try and solve the problem by yourself.

So we saw what a newcomer would do. Now, how would a more experienced developer handle this annoying but frequent situation?

First, before we can solve the bug, we have to spot the bug. If an exception is raised, well, you can easily tell the location of the bug. Otherwise (referring to logical bugs):

If you work with a good IDE, like Visual Studio, Eclipse, PyCharm, etc., you can run the program step by step, check your variables’ content, and spot the line/function that fails to run properly. If not, you can print checkpoints to see where the code reaches before it breaks, and you can print your variables’ values to see what goes wrong. Of course, the first approach is preferred as it’s easier and more convenient way of working.

After spotting where the bug occurs, you should start looking for why it does. Usually, you’ll find a problematic value of one of the variables on the line of the bug (can be a never raised flag, a never incrementing counter, a null or falsy value, etc.). If the problem is not variable related, it might be an uninitialized object, unopened connection, or other things you might forget to do – import a library, reset a connection, etc.

Now, what’s left is to trace the problematic variable’s value, see where it’s assigned wrongly, and find a way to fix it (or at least find the cause to the problematic assignment). If you don’t know why a specific function does not function as you’d expect it to, what a specific class does, or what a weird error means, always remember that GOOGLE is your best friend. Googling your problem does not make you a bad programmer. It actually makes you a better one – a programmer that can find his needed information by himself.

Now, you should remember. Debugging is not a science, it’s an art. It doesn’t have a clear step-by-step solution. Always start debugging “open minded” – bugs occur because of strange reasons, in unexpected places.

Also, remember that there is nothing wrong in asking for help – never feel ashamed to ask your friends/a programming forum/StackOverflow for answers. But also remember that other people will be more open to help if you show them that you at least tried to deal with your problems. Don’t let them feel that they do your work.

And finally, a good programmer that uses the methods described here, Google and friends in a wise and balanced way would find and fix his problems a thousand times faster than a programmer that every bug he sees equals to another phone call his experienced friend receives.

So in one sentence: Do your best to investigate it using the tools you have, and ask others only if really needed.

Software     , , ,