Programming Essence-writing high-quality C language code (6): Tracking the program by article

the best way to find a program error is to execute the program. During the execution of the program, we use our eyes or the tools of automated testing such as assertions and subsystem conformance checks we write to discover errors. While assertions and subsystem checks are useful, there is no guarantee that the program will not have a problem if the programmer does not anticipate that some issues should be checked beforehand.

The programmer can set breakpoints in the code, follow the code in steps, and observe the process of input becoming output. The best way for programmers to test their programs is to track the program one by one, and to take a serious look at the results in the middle. It takes time to trace the code, but it's just a fraction of the coding. Once you've followed the code one by one, we'll set breakpoints and track the whole process in a moment.

do not wait for the error to follow up the program.

in the essence of << programming-writing high-quality C language code (4): The end of system fortification (i) >> said: Error handlers are often prone to errors, is because they are seldom executed. So when we are tracking the code, we can simulate the error condition, and then we can observe the operation of the error-handling code. In addition to the error-handling code to track-by-article, each of the possible paths in the program are tracked. For example, if and switch statements, some are not very obvious, for example: &&,| | And? : operator.

Each code path is tracked by article by line.

The real effect of tracking code is that it allows us to observe the flow of data in a function. If you look closely at the data flow while your code is tracking , you will find the following common errors: Overflow and underflow errors, data conversion errors, error errors, null pointer errors, use of garbage information to populate memory unit errors, = instead of = = Assignment errors, and so on.

Keep a close eye on the data stream as you track your code.

One problem with the source-level debugger is that a single step crosses the &&,| | And? : Two paths, which leads to some problems. Consider the following scenarios:

if (Psym!=null & Psym->name!=null)
{
Freememory (Psym->name);
psym->name=null;
}

It should be seen that the program source code should be intended to use logic with, rather than bitwise AND operator, so even if the expression left is false, the right will still run (now access to the null pointer will also cause an error, but the author's book says that there is no error in the desktop system at the time). There are two ways to solve this problem: the first is when we track the program one by one, just step into && and | | When the conforming operator is used, the debugger command displays the results of each comparison in the condition. The second method is in assembly language step to compound conditional statement and? : Inside the operator.

The source-level debugger may conceal the details of the execution, and the key part of the code will be compiled instruction-level-by-article tracking.

Summarize:

1, if you want to find errors in your code, there is no better way than to track them every time you compile your code.

2, be sure to track each code path by article.

3, in some cases may need to be in the assembly language level code tracking.

Finally, summarize this article with the author's sentence in this chapter:

The code does not produce errors on its own, and errors are the product of programmers writing new code or modifying existing code.

Programming Essence-writing high-quality C language code (6): Tracking the program by article