If you are one of the many programmers who debug with
console.log, or the like, you miss a lot of features that debuggers can provide. If you often get stuck in debugging logic bugs, you can try this feature of your IDE.
Move past console.log
Logging debug output to the console is of course very necessary in many situations. Sometimes it’s good to just log an object and see the value it̵
However, once things get more complicated, a debugger can come in handy. Debuggers allow you to set breakpoints in your code and iterate through their execution. They also allow you to inspect the memory of your application as it changes with the execution of a function. This can be crucial for troubleshooting.
They are quite easy to use. The exact implementation depends on your IDE, but most of them allow you to set breakpoints by clicking on the sidebar, which will usually display a red circle to indicate that the code stops there.
Then you can just click start, and the debugger will pause when the breakpoint is reached (if ever). For example, you can set a break point when a particular button is pressed, and the program will run normally until the button is pressed. After the breakpoint is reached, the program will pause completely.
While it is paused, you can view the variables of the application. This is configurable and is automatically set to whatever Visual Studio thinks is useful. You can view variables manually or view only the local variables.
In this case, it is helpful to view the raw data for the class. For example, the list class just looks like a
objectIn practice, however, it has many other variables in the class itself. Not enough of course, but it is interesting to be able to see what is being allocated.
Get in, get out, transfer
Of course, pausing the program isn’t very convenient, so debuggers have tools to essentially play the execution frame by frame, line by line in this case.
You’ll find the controls in Visual Studio here at the top, underlined in red.
These all do different things.
- Get in makes the debugger go line by line, but also basically shows you every line it executes. When you call one of your functions, it will go to or “step in” that function. Once the feature returns, it will exit.
- Change also goes line by line, but in this case it is limited to the current scope. It won’t go into function calls, but instead literally moves to the next line in your source code, regardless of how many functions were called in the end.
- To get off in fact fast forward to the next
returnstatement, step out of the current stack frame. This allows you to exit functions after seeing enough.
With these three controls, you have full control over the program and can watch as much or as little of the performance as you want.
Meanwhile, as you step through the code, you can view the memory and local variables for each function, examine their values, and see how they change as you step further in time.
Conditional breakpoint settings
In Visual Studio, breakpoints can be more than just “stop on this line of code.” You can set conditional breakpoints that fire only when certain conditions or values are met.
Right-click on a breakpoint and select ‘Conditions’.
From here you can set an if statement that will be checked before the breakpoint is executed.