Code static check tool PC-Lint application practices

Code static check tool PC-Lint application practices

How to submit zero bug products and how to discover bugs as soon as possible is a problem that must be considered by both software development engineers and test engineers. I think high-quality code is the key. The specific implementation measures include framework constraints, code review, and test case design and execution.

L framework constraints can free programmers from coding without nutrition and error-prone code. Programmers only need to write some configurations or descriptions to generate a runable code framework from the framework. This not only improves the programmer's work efficiency, enables the programmer to focus on business logic implementation, but also forms a unified style and code structure for the program due to framework constraints. At the same time, because the Framework Code is automatically generated, this Part has been strictly tested to ensure high quality code and greatly reduce the number of bugs.

L code review, you can find some surface problems, such as lack of comments, a large number of global variables, and obvious bugs (such as using copy without knowing the length of a string ), this includes two factors: the basic quality of programmer coding and programming style. A good programming style can fundamentally reduce bugs and reduce code maintenance costs.

L the design and execution of test cases can discover some code logic problems, and it is also a protective screen to test program robustness.

In the actual project implementation phase, there may be no framework constraints, and the development team is busy with tasks. In the early stage, they do not have much time to review the code. So how to ensure the high quality of the code? Our test team researched and used a static code analysis tool PC-lint, which is similar to automated source code review, so that in the early stage of the project, the tester except for writing test, you can also detect bugs in the program as early as possible and provide developers with suggestions for modification.

PC-Lint is a static C/C ++ code check tool developed by gimpel software. It supports almost all popular editing environments and compilers, such as Borland C ++ from 1. X to 5. x versions, Borland C ++ build, GCC, Vc, vc.net, source insight, and so on. It also supports a 16/32/64-bit platform environment. It consists of the following files:

• Execution files in Lint-nt.exe windows
• Msg.txt all options help description file
• PC-Lint.pdf help files
• Config.exe configuration program
• STD. LNT standard configuration file
• Options. LNT option configuration file
• Configuration files of various development and compilation environments under the. \ LNT subdirectory

Because the executable file lint-nt.exe exists in the region, we can integrate it into the editing environment, such as vc6. Command Parameter example of PC-lint in vc6 environment-u-ic: \ lint STD. LNT $ (filename ). Command Parameter example of PC-lint in source insight environment D: \ lint \ lint-nt.exe-u-ic: \ lint STD. LNT env-Si % F. If you need lint to open all files in the same directory of the file, you can change % F to % d \*. CPP.

STD. the LNT file can contain other configuration files and various configuration options. It is similar to the C header file and can include many other header files, however, if the PC-Lint configuration file contains other configuration files, you do not need to write the include file name directly. An example of STD. LNT content is as follows:

// Microsoft C and Visual C ++ 6.x,-Si4-SP4, lib-stl.lnt lib-w32.lnt

// Standard lint options

 

Au-ds.lnt

Co-msc60.lnt // The alarm shielding file for vc6 provided by PC-Lint

Lib-stl.lnt lib-w32.lnt // The alarm shielding file for STL and vc6 library header files provided by PC-Lint

Options. LNT-Si4-SP4 // custom option File

Env-vc6.lnt // configuration file used to set the editing Environment

-ID: \ vc6 \ vc98 \ include // include directory

If you integrate PC-Lint into an editing environment, the input format must be consistent with the corresponding environment to ensure that when you click (or double-click) an error message entry, can be automatically located to the corresponding source code line, this type of configuration is placed in the env-xxx.lnt file, these files in the PC-Lint installation, it comes with, in. \ LNT subdirectory, such as vc6 is env-vc6.lnt, sourceinsight is env-si.lnt. We just need to find the env-xxx.lnt file that matches our editing environment and write it into STD. LNT.

After the source code is linked in the editing environment, we can use the PC-Lint command for static checks. It can be said that it is a more rigorous compiler that can not only identify common syntax errors, but also check those errors that are likely to be hidden and hard to be found, although in line with syntax requirements.

 

PC-Lint alarms are divided into 0 ~ Level 4, where level 0 is an internal error or fatal error, level 1 is a syntactic error, level 2 is a warning, Level 3 is information, Level 4 is optional, level 4 is disabled by default. The alarm level is defined in the following table,

	C	C ++	Warning Level
Syntax errors	1-199	1001-1199	1
Internal errors	200-299		0
Fatal errors	300-399		0
Warnings	400-699	1400-1699	2
Informational	700-899	1700-1899	3
Elective notes	900-999	1900-1999	4

Everything has two sides, and PC-Lint is no exception. It also often has some false positives. To eliminate these false positives, we have to use some PC-Lint options to block these alarms. Common options are as follows:

• -I Option

This option is mainly used to set the include path

For example,-ID: \ vc6 \ vc98 \ include

• -E # Option

This option is mainly used to shield the alarm with the alarm number #.

For example,-e818 indicates that the alarm with the alarm number 818 is not displayed.

• -Esym (#, symbol name) Option

This option is mainly used to shield the alarm of a symbol whose alarm number is,

For example,-esym (39, STD)

• -Emacro (#, macro name) Option

This option is mainly used to block the alarm of a macro whose alarm number is #.

Where, 0 ~ Level 2 alarms cannot be blocked using the-e option, but can only be blocked using options such as-esym,-emacro, and-Sem. Level 3 alarms must be based on the actual situation, some can be blocked using the-e option, and some cannot.

Through the analysis of PC-Lint alarms, We have summarized some C ++ coding specifications.

1. Excessively dependent on the operator priority rules in the C expression; for example, else if (m_nsize + step_keycount> m_nmaxcount), it is best to add parentheses.
2. The variable is defined, but it does not work.
3. Try not to allocate memory in the constructor; otherwise, an error 1732 is reported.
4. A function can be declared as a const type. Generally, some functions that do not modify member variables have such alarms as error 1762.
5. Member variables are not initialized before use.
6. The class pointer member is not released, especially when an exception returns, the pointer member is not released, which can easily cause memory leakage.
7. When using pointer members, no NULL pointer is determined.
8. In the design phase, you need to think about the interface variable type to reduce the frequency of type conversion.
9. The judgment condition is incorrect. This is a logical error. The use of PC-Lint is also difficult to check out, requiring developers to be especially careful.

In short, PC-Lint is a simple and easy-to-use static code check tool. It can help developers check for syntactic logic errors and improve the space utilization and running efficiency of programs. It can also help testers to check whether the source code complies with the C/C ++ coding specifications and whether there are syntax errors, such as unmatched parameters, unused variables, and NULL pointer references. If the level of the tester is high, you can also find out the logic and rationality of the Code, such as inappropriate loop nesting and branch nesting, and unacceptable recursion and suspicious calculation; you can also use the static check results for further error detection and provide some guidance for writing test cases.

Http://www.cnblogs.com/qingxia/admin/Files.aspx