Prata 1: A Point About Breakpoints

feature image

Prata 1: A Point About Breakpoints

Welcome to my first non-quata post. I decided to call this one a prata, which stands for productivity kata. I thought I’d do something different this time, and I picked this common mistake that I’ve seen new developers make when they pull me into their cubes and ask for help with debugging their code.

First of, why talk about productivity? In my opinion, a person who possesses a code quality mindset is also likely interested in enhancing their productivity and thus, their quality of life. They can do more work in less time. They can focus on their code more because they don’t have to struggle with other matters, such as the topic at hand.

Okay, let’s move along. What do you think about the screenshot below (don’t mind the code this time)? Do you fancy those red balls lined up on the left side of the code? If you think it looks perfectly normal, you’d better read on, my friend.

Unfortunately, this is a sign that the developer does not know how to use their IDE. Yep, this concept of using the right tools for the job is a recurring theme, I realize, and rightly so.

So, in this case, their intention is to be able to stop at each line and see it execute. I’ve never asked them how and why they started doing it that way, but I have a theory.

In IntelliJ IDEA at least, the Play-looking button (see the icon inside the red circle in the screenshot below), which is actually the Resume Program button, is more prominent or perhaps just better positioned than the Step tools (the ones inside the green oval). I don’t remember how it is anymore in other IDEs, but if a developer has only ever used IntelliJ, they have likely never noticed those Step tools.

The Resume Program button resumes the execution of your program until it encounters another breakpoint. I’ve literally seen developers add a breakpoint on the next line, click that button, then do it again and again, until their code is littered with breakpoints.

I then of course politely point them to those nifty Step tools above the window. The first icon is Step Over, which is exactly what they want to do in most cases. It executes each line, without stepping inside the methods, should you run into method calls.

There are also the Step Into and Step Out tools, which let you step into the method being called on that line and step out of the current method, respectively.

If you have never heard of these tools before, I highly encourage you to employ them in your next debugging session. They will likely look different in your IDE but these tools, however they look, and wherever they are positioned, are staples. If your IDE does not have them, switch to another one! S.e.r.i.o.u.s.l.y.

I think that you will find debugging more enjoyable (okay, less painful), and I’m sure that you’ll be more productive. It pays to explore your IDE.

Leave a Reply

Your email address will not be published. Required fields are marked *

Post navigation

Previous Post :