Debugging is a vital part of programming. A breakpoint — which by definition is an intentional stopping or pausing place in a program — is often key during the debugging process. They allow developers to gain insights into a program’s values during its execution — at which point said values may change to produce unexpected results upon completion. Having breakpoints means the execution will pause at different stages for the developer to inspect a certain value. By having the opportunity to then run each line of code after the breakpoint one by one, it is very easy to spot where things went wrong.

Every integrated development environment (IDE) nowadays will contain an integrated debugger allowing for these breakpoints to be put in place. And what’s more, it’s very easy to do so! All IDEs I’ve worked with have adopted the same method for applying breakpoints — you click outside of a particular code line just before its number. That line of code will more often than not contain a condition that needs to be met, and when it has been met, voila. Your application will pause when it hits that point — allowing you to look at the current state of variables, classes, config objects, and many more. This is extremely useful in cases where your program is returning an unexpected value. By hitting the breakpoint and gradually executing the code that comes after it, developers can gain a deeper understanding as to where an incorrect value is being set and why.

I find the origins of such programming features fascinating. Recently, I wrote about software bugs and how they got their name. This time, I went back in history to learn about the origin of the breakpoint.

#computer-science #programming #debugging #developer #data-science