Emanuele Feronato

Talking about PROgramming.

In a perfect world, our software never run in an unexpected way.

Unfortunately, we don’t live in a perfect world, so sometimes (quite more than sometimes) we have to face some strange errors.

That’s when we must learn the gentle art of debugging

Follow me through easy steps and you’ll wipe the bugs out of your life

1) A bug never appears “sometimes”

Believe me, the word “sometimes” has been invented for losers. A drunk would say he “sometimes” gets drunk, but in my opinion he gets drunk EVERY TIME he drinks too much. That’s another way to live your life. “Sometimes” means you don’t know when. You can’t live this way. You are a programmer.

So, you must know when your script has a problem. Exactly. Try to replicate it. Insert breakpoints, print variables, do whatever you can to recreate the problem EVERY TIME you want.

Do you want an example? … let’s see this script

a = a random number between 0 and 9
b = 10/a

This script sometimes crashes… but you must know when it crashes… and we can say the script crashes EVERY TIME a = 0, because of a divide by zero error.

When you can describe the problem starting with EVERY TIME, proceed to step 2

2) A bug never appears for the sake of appearing

Believe it or not, Gods aren’t upset with you. There isn’t any virus in your computer. “THEY” aren’t trying to drive you mad, and leech your brain because they want to rule the world.

The bug appeared for a reason. In the previous example, the reason was a number cannot be divided by zero. It’s not a plot against you. You simply cannot divide a number by zero.

You must understand why your script does not work… in this case it was a division by zero error, you have to find your case.

Now you know when the bug appears, and why it appears

3) A bug is a useless creature

Ok, bugs are the only good actors I can see in horror movies for a couple of years, but they are quite useless… and maybe they can survive to a nuclear war, and I don’t really want to survive to a nuclear war just to face giand radioactive bugs, so make up your mind, you don’t need bugs.

I mean you must find a way to get what you want with no risk to encounter a bug. In our example, you must decide if you really need a random number between zero and 9, or if a number between one and 9 would do.

With numbers from 1 to 9 you solved the bug, but sometimes you may decide you need the zero too, and in this case you would perform the division only if the number is different than zero.

This is the step where you must decide if you want to obliterate the bug or handle it as an exception.

Needless to say the first option is the best, because you can manage one, two… maybe five… TEN exceptions, but sooner or later your script will collapse if you work this way.

4) Put a big shoe on the bug’s head

It’s the time to rewrite the bugged code… keep in mind what your script is intended to make, and what you don’t want to happen. Since at this time you will probably are a bit tired, proceed step by step. Throw a shoe to a bug from a big distance, and you’ll miss it. Get closer and closer, until… SQUASH! It will know the power of the mighty shoe.

5) It wasn’t a simple bug. It was a cyborg bug

If your bug dies with a little red light fading away, and you can hear something like “I’ll be back”… then it wasn’t a simple bug… it was a cyborg bug. In real life, fixing a bug can bring new bugs to life.

In my previous example, I can fix the bug setting a as a random number between 1 and 9.. but I can fix the bug coding the second line as b= 10/(a+1).

According to what I am expecting from the script, one of the ywo ways of fixing the bug can make the bug return later. You have to forecast future bugs and prevent them

That’s all… this was obviously an ironic post, but there is some truth in it… how do you debug your scripts?