Welcome, I’m Jim Lavin and this is Coding Smackdown, the netcast where we put a headlock on the coding lifestyle.

This episode is rated G for the insightful wisdom of the coding guru we are about to impart.

Once upon a time there was a mechanical engineer, an electrical engineer and a software engineer riding through the mountains and as they started to go down a steep incline the brakes gave out and they careened down the incline and crashed into the guard rail.

The three engineers got out of the car scratched their heads and looked at the car.

The Mechanical engineer said “We should look at all of the mechanical systems, test each one separately and determine which one is malfunctioning and fix it.”

The Electrical Engineer said “I got a better idea, lets hook my diagnostic scope to the on-board computer and it can tell us which system failed and we can then fix it.”

Then the Software Engineer said “I got an even better idea, lets just push the car back up the mountain and get in and see if it happens again!”

Over the past couple of years I have been a technical lead on a large global virtual team and I have spent hundreds of hours mentoring developers and one of the most important skills I see lacking is the ability to debug an application.

Developers too often waste their time rerunning an application and guessing why an error is happening instead of using the debugger to step through code and find out what is really happening inside their code.

Not only does the debugger help you find out what is happening inside your code it can be used as a valuable training tool when you are trying to learn a new framework or understand how a pattern executes.

Most any Development Environment provides an integrated debugger that allows you to single step through your code to see what is happening and where things are going wrong.

There are five things you need to get familiar with, in order to use the debugger effectively:

The Debugger Commands
Setting Breakpoints
Viewing Local Data
Setting Watches on Data
Viewing the Callstack

There are several commands that are common to all debuggers.

Those to start the debugging process and those to navigate with while debugging an application.

Usually your development environment will include a command to start the debugger. In Visual Studio this is normally the F5 key or you can select Debug | Start Debugging from the main menu.

If you are trying to debug a process that is already running, development environments usually provide a way for you to attach to an existing process. In Visual Studio you can do this by selecting Debug | Attach To Process from the main menu.

Once you’ve started the debugger you need to be able to control how the computer executes the code. There are usually several commands that allows you to step through the code or jump to a location in the code.

The most common commands are;

Single Step which allows you to execute a single line of code and stop.
Step Into which allows you to step into a function call and continue debugging.
Step Out which allows you to continue execution but stop once a function completes executing and returns.
Run To Cursor which allows you to set your cursor at a line of code and have the debugger run until it hits the line where the cursor is.

If you don’t want to walk through every line of code but stop when you reach a specific function or method within your code, then you want to use break points.

Breakpoints allow you to stop the execution of your code so you can step through it at a desired location.

There are several ways you can set a break point:

By Location – this is when execution reaches a specific function or line of code in a specific file.
By Condition – when a break point location is reached, an expression is evaluated and the break point is hit only if the expression is true.
By Hit count – when a break point location is reached and the hit counter has reached the number of hits to equal the expression. You can stop on a specific number of times, less than a specific number or when the hit counter is greater than a specific number.
By Filter – This is a way to restrict break points from happening based on Machine Name, Process Id, Process Name, Thread Name or Thread Id. This can be really great if you are trying to debug a single thread within a multi-thread application.
By setting a breakpoint you can run your application and every time the debugger hits the break point it will stop so you can single step through your code.

So now that you’ve set your break point and reach some code you want to debug what do you do next?

As you step through the code line by line, you’ll probably be interested in what the values of your variables are as you execute each line of code.

Most debuggers provide a Locals Window that allows you to inspect the values of the variables and object within your code as you step through it.

By using the Locals Window you can see exactly what affect each line of code has on your data. You can also inspect the variables passed into your methods to ensure the right data is getting to your code.

9 times out of 10 an application fails because of bad data. Using the Local Windows as you step through your code will help you catch those issues.

There might be times where you want to track the state of an object over time, the Watch Window provides a perfect place to do that.

The Watch Window allows you to keep track of the state objects as you execute your code that may be in different modules or objects.

The Watches Window allows you to inspect a global variable or object as you execute code. It works similar to the Locals Window but only shows those variables or objects you have set up watches for.

The nice thing about the Watches Window is that you can use it to filter out local variables that you are not interested in. This is really useful when you have a method or funtion with a lot of local variables.

So now, you are stepping through your code and you know how to inspect the data within your application as you step through it, next we’re going to show you how you got to your code by using the call stack.

The call stack is the best way to find out how your code got executed.

It gives you a list of each line of code that was called previously in order to get to where you are now.

If you want to see what line of code called your code, you can usually click on a line in the Call stack and you’ll be taken to the code.

Now you are armed with the enough knowledge to quickly find out what is going wrong in your application.

If you are new to a framework library or want to see how a piece of code works you can use the debugger if you have the source code.

Just set a couple of breakpoints in your code and step into the framework and walk the code step by step to get a good idea of what is going on under the covers.

For example if you want to step through the .Net Framework in Visual Studio select Tools | Options from the main menu and Go to the General Option under Debugging and select Enable .NET Framework source stepping. This will make changes to your debugging environment that will allow you to step into any .NET Framework code next time you are in the debugger.

One of the first things I do whenever I start using a new framework or library, is install the source code and step into the code in order to figure out how best to use the library.

Trust me this is one of the best uses of the debugger you’ll ever find and provides you with a quick and easy way to find out what other libraries are doing.

So there you have it, next time you need to figure out why your code is failing, instead of re-running the application and see if it happens again, set a couple of break points in the debugger and walk through your code step-by-step, you’ll find the reason your code is failing and be able to fix it faster.

If you have comments or questions leave us a comment on the show notes for this episode at http://codingsmackdown.tv

I’m Jim Lavin and we’ll see you next time on the Coding Smackdown!