Geek Answers Handbook

What is your favorite way to debug your program in Visual Studio?

On this day, I came up with great software.

I need to debug Visual Studio 2008.

I am doing the following steps:

  • Using the call window to find blocks of code that I think might have errors.

  • Using instant windows to invoke some local functions to see if the data structures in these blocks are correct.

  • When I got the result in step 2, I have to go to step 1 to find the source of the error again using callstack.

What is your favorite way to debug a large or small program in Visual Studio?

I don’t think that debugging is a good way to run the entire program and view the entire associated data structure.

+4
source share
6 answers

Putting breakpoints in suspicious methods and using Immediate Window is my way. I am a big fan of Immediate Window .

Also conditional breakpoints are another way that I like. especially when I repeat the collection to find a suspicious object. I put the condition on the breakpoint and press F5 to get it.

Combination

Ctrl + Alt + Q is another good shortcut to the quick view window for analyzing an object.

+3
source

I prefer unit tests using the direct window, mainly because it means that I can run the code over and over again very simply (and indeed from the build script).

If you find a problem using the direct window and fix it without adding any tests, you will not be warned if the same problem returns again. With unit test, you have a constant companion to make sure that any future changes do not return an error.

Personally, I don’t like going through the code - I find it disappointing compared to unit testing. It is too simple to accidentally step over something that you would like to intervene, etc. This is sometimes necessary, but often it is a sign that your code is too complex. I especially don't like debugging the whole application, and not just going through the unit test into the debugger. It is usually orders of magnitude slower.

+3
source

My favorite way when introducing into a great application:
- Always: “Read the entire code” to the end (this is the most interesting)
- Bookmark the central parts of the code.
- Refactoring and checking records during debugging

+1
source

To find code that distorts the value of a variable, I create a data breakpoint for this variable. The program interrupts its execution each time the variable data is changed either with the correct code, but also with the help of a wandering pointer.

+1
source

One of my AHA moments in debugging VS200x was that I could use "Attach to process ..." to start debugging an executable file that was already running. For larger solutions, it is surprisingly often faster to run the application in "normal" mode and then connect Visual Studio to it compared to the start of a debugging session by pressing F5.

0
source

An important point for debugging, in my opinion, is the formation of a theory about where the error may be. In other words, try to take a look at the code and think about the problem before running the debugger.

I asked a similar question , so you can also check the answers to this.

0
source

More articles:


All Articles