Wouldn’t it be cool if we wrote programs that ran smoothly all the time every time? No, I don’t think so. I think it would be boring if we never had to anticipate bugs in our work. Bugs are flaws in our code that cause our programs to fail or give unexpected results.
Debugging can be a tedious process and many times that is because of the way it is done. This article focuses on just one way of debugging on Visual Studio Code. An IDE (integrated development environment) by Microsoft that can run on any operating system.
Visual Studio has a debugger tool that assists in identifying bugs and making getting rid of them a lot more easier. I learnt about this feature when I started learning C#. In the book, Head First C#, all exercises and projects are done on Visual Studio so some parts of the book teach about Visual Studio. That gained the book more points in my “book”.
I have used Head First C# as my reference material in this article as well as using a code snippet as an example.
Anatomy of the debugger
When your app is paused in the debugger -that’s called “breaking” the app.
Controls explained in order from left to right
The stop execution button that stops your app from running.
The program is currently being executed, when it’s not, the stop icon is replaced with a play icon.
Step Over. Executes the next statement. If it’s a method it runs the entire thing.
Step Into. Executes the next statement, if that statement is a method, it only executes the first statement in the method.
Step Out. Finishes executing the current method and breaks on the line after the one that called it.
Read on to find a fun activity at the end
How to use the debugger
The debugger helps you see how your variables change throughout different stages of execution of your program.
-
Add a breakpoint and run your program.
Remember a breakpoint is where you suspend running your code, to know the value of the variables
This is a code snippet of a loop in C#.
Highlight the line above your method call and on the Run menu at the top menu bar and select Toggle BreakPoint or press F9. That highlights the method call below it in red and adds a red dot at the beginning of the line.
Press the start execution button (play icon at the beginning of the debugger toolbar).
2. Step into the method
The debugger has stopped on the statement that calls OperatorExamples; the “breakpoint“. Step Into causes the debugger to jump into the method then stop before it runs the first statement.
The debugger is now on the opening statement of the OperatorExamples method.
At this point if you hover over any of the variables their value is 0, because we have not gotten to the point where they get assigned a value.
Try hover over p on line 15 and see what value p has.
Press Step Into to execute each line at a time inside the method.
The debugger is now on the initialiser of the for loop (first statement of the for loop). If you hover over p you’ll now see the value is 2 because it has already been initialised.
As you continue stepping through your code and get to the while loop and the condition of the while loop is not met, as expected, the debugger jumps through the while loop and goes directly to line 23. The statement after the while loop.
Keep hovering over the variables and not how they change after each statement.
Step into will stay inside the for loop until the condition is false, that’s when the method gets to the end.
Read more about Visual Studio Debugger
I use step into more because it executes a method statement by statement. This too is quite helpful in situations where your algorithm is long and you can’t just spot the bug by looking at your code.
3. Step Out, just from its name, finishes executing the method the debugger is in and breaks on the line after the one that called it.
Use the debugger to figure out how many times the for loop loops and how many times line 20 p = p*2. Leave your answers on the comments below 😀
