The king of debugging
You know him, everybody does.
print("I am here")Isn’t he great? He never let you down when you needed him, he never failed. Unfortunately, he has one big problem, he wastes your most valuable resource. Time
But, what do you mean?
Imagine being a line painter on a highway, your job is to paint lines across the highway. You have a variety of options to accomplish your task. You’ve started. First 10 meters were easy you just soaked the brush in the paint and started painting, first meter, second, third and you ran out of paint, so you came back to bucket with paint and again soaked the brush in it, you came back to the point where you finished. fourth, fifth, sixth meter and so on. After twenty times walking back and forth you started to feel tired.
This is when you are printing in your code. You will eventually find the issue, but it will cost you more effort and time.
Debugging tools
Most of the IDEs and great text editors have debugging tools. If yours don’t, you should switch it then.
Breakpoints
Probably the best debugging feature ever made.
Let’s show it in practice. We want to write a program that makes three steps forward (in a strange way). This is the code with a bug. I’ll be using C#.
static int MakeThreeStepsForward(int currentStep)
{
int newSteps = currentStep - 2;
newSteps = newSteps + 5;
newSteps++;
return newSteps;
}
Can you spot the bug? Of course, you can because it is a super easy example. But let’s say you don’t. So what would be the first thing you would do? Print statements (Console.WriteLine()currentStep = 2
static int MakeThreeStepsForward(int currentStep)
{
Console.WriteLine(currentStep);
int newSteps = currentStep - 2;
Console.WriteLine(newSteps);
newSteps = newSteps + 5;
Console.WriteLine(newSteps);
newSteps++;
Console.WriteLine(newSteps);
return newSteps;
}
The output of the program is 6, expected is 5. And there are our prints
2
0
5
6This is not very readable, isn’t it? At this point, you start analyzing console output with the code. All right the bug can be fixed in the first line, there can be -3 instead of -2. It still isn’t hard, but this is “alghoritm” that has 4 lines of code. Imagine doing so in 40 places in your code. It would be a nightmare.
Now let’s jump to example with breakpoints
Breakpoints are stopping the program at the beginning of the line, not the end!
By creating a breakpoint on second line program stopped, showed values and you could inspect every value in the current context, you can check out everything just by creating one red dot! No more prints!
Remember our highway painter? He found a perfect solution on how to speed up his job, he started taking the bucket with paint with him! No more going back and forth. This is when you use breakpoints.
More tools
Every IDE or text editor that supports debugging has a lot more debugging tools, conditional breakpoints, function breakpoints, call stack, live watches and more! You should definitely check out what your editor has and not be afraid of them! This is key to fast and efficient development.
Debugging friendly editors
Most of the IDEs have great debugging tools, but not all the text editors. Personally, the best text editor for a programmer is a Visual Studio Code, it has a huge amount of community extensions, it is fast, and has great debugging tools!
Conclusion
I was surprised that my friend who is definitely not a beginner programmer still uses prints instead of proper debugging tools, they are not decorations, use them! Sit for 30 minutes and try what they can do, you’ll thank yourself later. Also, I’ll write about using some debug tools in detail. It was an introduction to the idea of debugging.
Update 1
It’s worth to notice that there are some cases where using print is fine.
Chris Code 