Debug Mode

1 - What is debugging?

Debugging is what developers do to iterate over the code while it is running. This allows us to access bugs and analyze them, since without it, finding and fixing errors would be much more complicated. 

Additionally, keep in mind that Visual Studio (or our IDE) needs to be in Debug Mode, in VS this option is at the top of the menu

To start iterating through the code, what we need to do is click the "play" button, which is also shown in the image above.

Once inside, we'll iterate through the code. 

int contador = 0;
do
{
    Console.WriteLine("Iteración número " + contador);
    contador++;
} while (contador < 10);

2 - How to debug code

But to actually debug the code, we need to add breakpoints, and to add them we have three options.

1. Place the cursor on the line and press F9
2. Right-click on the line > Breakpoint > Insert breakpoint
3. Click on the left margin of the file with the left mouse button, and it will add a breakpoint

Once you've added a breakpoint, you'll see a red dot, which indicates there's a breakpoint (it's the same dot from option 3), and the line will be highlighted in red.

When the program is running, it will automatically stop at the breakpoint, which will turn yellow, along with an arrow on the side of the file, indicating exactly where it is currently stopped.

Once here, you have several options to continue:

• F5 continues to the next breakpoint
• F10 Executes that line of code
• F11 Executes the next code statement, which means that if, for example, you're calling a method in that line of code, pressing F11 will step into the method.

Another option is to drag the arrow to the line you want or move it back, but you need to be careful as this can cause some exceptions if, for example, an element hasn't been declared. 

3 - Advantages of Debugging

As we mentioned earlier, we can see the program execute step by step, and that includes being able to see when and where corrupt data appears when the code breaks. This makes it easier to identify where and why such issues occur. 

We have access to the Call Stack, which includes every point the process has passed through:

If we double-click on any of them, Visual Studio will take us to that point, and not only that, but the variables will have the values they had at that point. This makes it much easier to check for errors.

When debugging, we have access to all available variables within the scope, so we can check their value or even operate with them in the Visual Studio watch box, which is especially useful when dealing with big blocks of information like lists of employees, etc. 

As you can see, the second line is our counter, and we've performed operations with it; this information is temporary and will not be stored in the code the next time you run it.

Finally, note that you can change the values of variables when stopped at a breakpoint, which can make it easier in some cases to check "what if..." scenarios, but personally, I don't recommend it.