The flag has always been set to start writing technical blogs to record their learning gains and experiences, but procrastination is too serious. I recently studied Larry Ullman's "C ++ Book for Everyone" and I really like this book. I saw Chapter 10 "Error Handling and Debugging" today and found it very useful, so I recorded it. Let's start with my first technical blog ~
Every mistake is a good opportunity to learn how not to make mistakes in the future. To master debugging skills, the most effective way to learn is to repeatedly try, make mistakes, and correct mistakes (then try again, make mistakes, and correct mistakes ... This process is often crazy, but the debugging is successful I really felt a sense of accomplishment ~)
Program errors can be divided into two major categories: compile-time errors and runtime errors
1 compile time error
This kind of error is actually easier to correct, after all, the compiler will tell us in detail what is wrong.
Here are some good experiences that people have summarized in preventing, finding, and correcting compile-time errors:
Cultivate and maintain a programming style; (especially when writing large programs, how to name variables and functions, how to write code in which format, how to indent code blocks, etc. are very important)
Take seriously the error / warning messages given by the compiler; (some warning messages are also useful)
Think twice: check first and then type; (modifying the source code rashly tends to make more mistakes)
Pay attention to check the most basic syntax; (Before starting to find and correct big problems, you must ensure that there are no minor problems such as asymmetry in parentheses in the code)
Change the potentially problematic line of code into a comment to see if the error is still there; (if the error is still on, it means the problem is not on this line of code; if the error is changed or disappeared, it means that the problem is indeed on this line of code)
Try another system environment or development tool;
Check whether all necessary files have been included; (header files, library files, etc.)
Pay attention to the scope and namespace of variables;
Take a break; (this is very important, relax and wait for your mind to come back to solve the problem)
Use debugging tools;
Save the debugged code separately and do not change it; (It is best to back it up before modifying the program, in case the worse the change, you can return to a less bad state ...)
After successfully finding and correcting a mistake, quickly recall whether you have made the same mistake elsewhere and modify it together;
2 runtime errors
Run-time errors generally do not have formal error messages, and are more difficult to find and correct than compile-time crops.
The program acts according to the code we wrote for it, so debugging a program is actually the process of determining what it is doing and why. Once it has mastered its ins and outs, it is much easier to find the wrong behavior, determine the root cause of the error and correct the wrong behavior. Here are some good experiences that people have summed up:
Cultivate and maintain a programming style; (Chaos is the biggest enemy of programmers, find your favorite programming style and habits, and then keep it)
Use more comments, use good comments; (If you forget the purpose and reason of a certain program, it will be very difficult to debug, and the comments should be synchronized with the code)
Pay attention to the priority of operators; (the safest way is to use parentheses to ensure the order of a series of operations)
Print out the values of variables to confirm whether they meet expectations;
Don't forget to check the legality of user input and file input; (users are not programmers, their input is often inconsistent with the expected input of the program)
Don't make any assumptions; (don't assume that an operation that should happen, such as opening a file, creating a new memory block, etc., will definitely happen successfully)
Do not ignore the warning messages given by the compiler; (warning messages often indicate potential runtime errors)
Divide the program into some smaller unit modules to test;
Use debugging tools;
Some other tips; (Let the function return an error code, use the assert () function, and catch the exception) (Since it is for C ++, I will not introduce them one by one here)
Although the experience summarized above is based on C ++, many things are actually interlinked, so you can also learn from and refer to debugging programs written in other languages ~
