A little summary of debug

 

Programmers often have to deal with bugs, and generally spend more time debugging bugs than writing programs.

Bugs can be simply divided into two categories:

1. syntax bug
2. logical bug

Syntax bugs are those that the compiler can recognize, such as the common lack of semicolons and parentheses, and the mismatch of data types when passing parameters. This type of bug is easier to debug. The corresponding error statement can be found directly according to the output information.

Logical bugs are very troublesome, and such bugs will not be displayed by the compiler. For example, the most common array out of bounds, illegal access to memory, these problems will not be recognized by the compiler, and will only be displayed when the program is executed. At this time, we often divide the program into blocks to determine which step the program can execute. There are generally two common methods at this time:

1. Set breakpoints

All IDEs now provide this function, and when the program runs to the breakpoint, it will stop directly.

2. Artificially add output statements

For example, the C language can use the printf statement to determine which step the program can execute.

These two methods have their own advantages and disadvantages, and "MIT: Introduction to Computer Science Programming" talks about things to pay attention to when debugging. It feels good to record it. (Also, as mentioned in the course, "print" and "re-read the code and think" are very important methods. Indeed, sometimes the single-step debugging of the debugging tool will make you limited to the details, without looking and thinking about the code as a whole. .But sometimes debugging tools can also help us a lot. Maybe a combination of the two will make debugging more efficient)

 

The following is a summary of some experience in debugging:

1. The arguments are in the wrong order. (Note the parameter naming to avoid reversing the order. Using the same name for the actual parameter and the formal parameter will make it clearer)
2. Misspell.
3. Forgot to initialize.
4. Object is equal to value. "==" and " = "
5. alias. Deep and shallow copies of arrays and linked lists.
6. side effect. Function execution may change the value of some variables.
7. Collect the mistakes you often make, and start with the easy mistakes when debugging.
8. Document the modifications you have tried, the "print" for debugging can be commented out instead of deleted.
9. When debugging other people's code, debugging is the code, not the comments. Don't be fooled by comments.
10. Get help. Bystanders are clear, seek help from others, and explain your procedures to others as clearly as possible. Maybe you can find mistakes in the process of explaining.
11. Wake up your brain.
12. Haste is not enough. Consider a good modification plan, rather than a quick success. The process of fixing this bug may produce more bugs.
13. Code cannot always get longer. The more code you write, the more likely you are to make mistakes. When you run into problems, try to clean up your code, maybe you might find bugs in the process.
14. Back up the old version code in time. Make sure your code can go back to Debug. There's nothing like 4 hours of debugging, only to find out that it wasn't as good as it was 4 hours ago, and it's more frustrating that you can't go back to where you started. Hard disk space is cheap, and there is absolutely no harm in saving more old versions of code.

Reference blog post : http://alorry.blog.163.com/blog/static/647257082011664510817/