When we write complex if statements, odds are we make an error sometimes. When that happens, we can look through the code in search for the mistake. Or we use Visual Studio"s debugging features. Let"s see how those features help with debugging if statements.

When we write if statements in our C# application, sooner or later we run into code that doesn"t behave right. Perhaps our nested if/else statement never runs or a cascaded if statement always executes the same code block. Either way, we"ll have to analyse our code and fix the problem.

Debugging is the process in which we identify and remove errors from our application (Asad & Ali, 2017). We can do that by looking through the code in search for the error. But a more efficient and scalable approach is to use special debugging tools.

One helpful debugging instrument is to step through our code. This executes our program line by line and shows how it behaves with each step (Asad & Ali, 2017; Dorman, 2010). Such a level of detail makes it clear why a particular if statement runs or why another fails to do so.

To see how we go about debugging C#‘s if statements, let"s explore a console application that has an error in it. After looking at the code we"ll explore which Visual Studio tools we can use in search for the bug.

The example console application helps a publisher find its next promising author. It has the following code:

We begin the Main() method with declaring and initialising some variables. Then we come across an if statement:

Here we use first use the logical NOT operator (!) to check whether the underContract variable is false. When it"s true that underContract is false, the nested if statement executes.

That if statement has a condition that consists out of two logical expressions. The first is whether the author has written more than one book (booksWritten > 1). The other checks whether his or her royalty amount is greater than or equal to 15% (royaltyAmount >= 15). This way our publisher hopes to find highly qualified authors that have proven their worth to other publishers.

Since we combine both logical expressions with the logical AND operator (&&), both need to be true before the entire condition is true as well (Sharp, 2013). Should one or both be false, then this if statement"s condition is false as well – and its code will not run then.

Now say we expect the Console.WriteLine() method inside the nested if statement to run. But when we execute the program, nothing happens. But even though that means there"s an error somewhere, our program doesn"t trigger an error message. Often programming errors are small, subtle mistakes that don"t thrown big errors when the program runs. That makes them hard to find, and keep them unnoticed for a long time. Let"s see how we can use Visual Studio"s debugging tools to find the mistake.

To explore our program and see what values the variables and expressions have, it would be ideal if we could pause our program just before the nested if statement executes. Luckily we can with Visual Studio"s breakpoints.

With a breakpoint we mark a line of code where we want the program to pause (Price, 2017). Then each time the debugger executes our program and reaches the breakpoint, it pauses just before it runs the line with a breakpoint on it (Dorman, 2010; Liberty & MacDonald, 2009). This way breakpoints are our way of telling the debugger: ‘pause before this line executes so I can inspect the program’.

Without something like a breakpoint, our program simply runs under the debugger till completion. That wouldn"t give us a chance to inspect the program at its intermediate steps. Now when the debugger pauses (also called ‘breaks’) our program, several helpful debugging tools become available. For instance, at that point we can use Visual Studio"s tooltips to inspect values, continue the program by stepping through code, and track how variables and expressions change in the ‘Watch’ window.

One way to place a breakpoint is with a left-click in the code editor"s left margin. That makes the line marked with the breakpoint appear in red and also place a red dot before the statement:

Now that we placed a breakpoint in our code, we need to start debugging in Visual Studio. That makes the debugger run our program and pause it whenever it comes across a breakpoint or unhandled exception.

We begin debugging with the ‘Start Debugging’ icon ( ; F5) from the ‘Debug’ toolbar:

Now just before the line with the breakpoint is about to execute, the debugger stops program execution (Liberty & MacDonald, 2009). Visual Studio then brings up the code editor and gives the breakpoint line a yellow highlight:

Once our program pauses under the debugger we can use several Visual Studio tools to analyse it:

• When we hover our mouse over an expression, a small tooltip window appears with that expression"s value. This way we quickly check what the current values are and whether they match our expected values.
• With the ‘Step Into’ ( ; F11) and ‘Step Over’ ( ; F10) debugging commands we step through programming code. That makes our program run just one or a few lines at a time, which gives a close view of how the program behaves.
• We can evaluate and even change variables with Visual Studio"s ‘QuickWatch’ window. Then when we step through code we can see how those changes affect our program.
• And with Visual Studio"s ‘Watch’ window we track variables and expressions so we see them change as we go through programming code.

Now let"s use one of these Visual Studio debugging features to troubleshoot our example console application.

The console application we introduced earlier has a problem: its nested if statement doesn"t execute even though we think it should. One debugging tool that particularly helps in situations like this are Visual Studio"s tooltips.

When Visual Studio"s debugger pauses our program, we can hover our mouse over expressions and variables. When we do, a small tooltip window appears with the value of the code element (Price, 2017). Based on where we place the mouse, the tooltip shows us which value a variable has, what an expression evaluates to, or how a collection or object is structured (Dorman, 2010; Sharp, 2013). This way we quickly check whether the value that our code assumes is also the one that"s present.

Since our example console application didn"t execute its nested if statement, we know that either that statement or the if statement above it prevents the nested if statement from running. So when our program pauses under the debugger, let"s use the Visual Studio tooltips to inspect those code elements.

We check the condition of the nested if statement by placing the mouse pointer on the logical AND operator (&&) like so:

Here we see that our nested if statement"s condition evaluates to false. When we assumed that this condition would be true, it"s worth to check its individual expressions separately.

When we hover the mouse over booksWritten > 1 we see that this expression is true:

Because this part of the condition is true, let"s verify the other expression:

This logical expression evaluates to false: royaltyAmount is not greater than or equal to 15. But since we combined both expressions with the logical AND operator (&&), both need to be true before the entire condition is true as well (Sharp, 2013). Since that isn"t the case, the nested if statement"s condition is false and its code never executes.

Let"s move the mouse over the royaltyAmount variable to see its current value:

Problem found! The royaltyAmount variable only has a value of 0.15, not 15. This makes the nested if statement condition false, which in turn prevents it from running its code.

The question that remains is whether this difference in values is by design or a bug. When we realise that royaltyAmount expresses a percentage, it looks to be an error: the nested if statement expressed a percentage as an integer while the royaltyAmount variable uses a decimal value. Once we fix this discrepancy and use a consistent scale, the nested if statement will have no trouble to execute its code when it"s supposed to.

Now that we found our error, we stop debugging. For that we use the ‘Stop Debugging’ icon ( ) from the ‘Debug’ toolbar (or press Shift + F5):

After we stop debugging, Visual Studio returns us back to the code editor where we make the necessary code adjustments based on what we learned while debugging. Then we remove the breakpoint. For that we click on the red dot in the code editor"s margin, or press F9 while the text cursor is on the code line with the breakpoint.

To troubleshoot our if statement code we can search the code for errors. But that"s time consuming and doesn"t allow for easy experimentation. A better option are Visual Studio"s debugging tools. With those we can closely inspect a program while it runs. That way we can lookup values of expressions, change variables, and even execute the program one line at a time.

We start debugging with the ‘Start Debugging’ ( ; F5) option. But before we do, we typically place a breakpoint to specify where the debugger should pause our program. Then every time when the debugger runs our program and reaches the breakpoint, it pauses just before executing that line. This way our program halts at areas where we want to take a close look.

Once our program pauses (also called ‘breaks’) under the debugger, several debugging tools become available. One feature is to step through code with just one or a few lines at a time. This way we see how running those lines affects the program. And with a debugging feature like the ‘Watch’ window we track variables and expressions and see how they change as we progress through the code.

When we troubleshoot if statements a particular helpful instrument are Visual Studio"s tooltips. When the debugger paused our program, those small windows appear when we hover the mouse over code elements. Those tooltips show the values of variables and expressions. This way we quickly check why an if statement"s code execute or why it failed to do so.