CN111552476A

CN111552476A - Method and equipment for static code inspection

Info

Publication number: CN111552476A
Application number: CN202010333073.8A
Authority: CN
Inventors: 陈林峰; 张利兵
Original assignee: Fiberhome Telecommunication Technologies Co Ltd
Current assignee: Fiberhome Telecommunication Technologies Co Ltd
Priority date: 2020-04-24
Filing date: 2020-04-24
Publication date: 2020-08-18

Abstract

The invention discloses a method and equipment for code static inspection, which relate to the technical field of computer software programming. The invention can not only perform single source code file check but also perform incremental check. Meanwhile, the invention can call PC-Lint to carry out multithreading concurrent execution, further shorten the inspection time, promote the enthusiasm of encoding personnel for code static inspection, and further improve the software quality.

Description

Method and equipment for static code inspection

Technical Field

The invention relates to the technical field of computer software programming, in particular to a method and equipment for statically checking codes.

Background

The software quality is the root of improving customer experience, the static code inspection is the premise of ensuring the code quality, and the problems are found and modified in advance through the static code inspection, so that a foundation is laid for software quality assurance.

PC-Link is one of LINT series products from Gimpel Software corporation, runs on a PC platform, and is a Software package for carrying out error check on C and C + + source programs. The basic working principle of the method is to perform source code analysis, value tracking and type check, and perform deeper semantic analysis work than a common C/C + + compiler, so that possible software defects are avoided.

Although the PC-Lint is powerful, the defects are obvious:

(1) the execution time of one large software project inspection is too long;

(2) the inspection of a single source code file cannot be conveniently carried out;

(3) the false alarm and invalid content in the inspection result are too much, the modification is troublesome, and some problems can not be filtered or shielded by modifying the original configuration file;

(4) the results of the last inspection and the last inspection cannot be automatically compared and analyzed, and the incremental inspection cannot be carried out;

the problems seriously affect the enthusiasm of encoding personnel for code static inspection, and further affect the improvement of software quality.

Disclosure of Invention

In view of the defects in the prior art, the present invention aims to provide a method and an apparatus for static code inspection, which can effectively shorten the inspection time.

In order to achieve the above purposes, the technical scheme adopted by the invention is as follows: a method of static checking of code, comprising the steps of:

adding a self-defined check filtering condition in the configuration file;

acquiring input parameters, determining a source code file to be detected according to the input parameters and a configuration file, and generating mapping from an engineering name to a source code file list;

lnt files are generated according to the mapping from the project name to the source code file list;

the PC-Lint is called through the command line, and detection is performed according to the lnt file.

On the basis of the technical scheme, the method for adding the customized checking and filtering condition in the configuration file specifically comprises the following steps:

adding a source code exclusion condition for custom checking a source code file to be excluded;

adding a directory exclusion condition for custom checking source codes or engineering files in the whole directory to be excluded;

adding project elimination conditions for custom checking of project files needing to be eliminated;

and adding result filtering conditions for customizing keywords or error codes which need to be filtered in the inspection result.

On the basis of the technical scheme, the method comprises the following steps of obtaining input parameters, determining a source code file to be detected according to the input parameters and a configuration file, and generating a mapping from a project name to a source code file list:

the input parameters comprise a directory name to be tested, a source code file name and/or an engineering name, and also comprise a corresponding specific path;

judging whether the directory name, the source code file name or the project name to be detected need to be eliminated or not according to the self-defined checking and filtering condition;

if the elimination is needed, the check is stopped; and if the project name does not need to be excluded, generating the mapping from the project name to the source code file list.

On the basis of the technical scheme, lnt files are generated according to the mapping from the project name to the source code file list, and the method specifically comprises the following steps:

generating a general user-defined configuration;

analyzing source file containing directories in the engineering files, and generating corresponding-i parameters for each source file containing directory and writing the parameters into lnt files; generating a corresponding-i parameter for the system inclusion directory and writing the parameter into an lnt file;

analyzing library inclusion directories in the engineering files, generating corresponding + libdir parameters for each library inclusion directory, and writing the parameters into lnt files;

and finally, writing the source file list corresponding to the project name into the lnt file, and finishing the generation of the lnt file.

On the basis of the technical scheme, the method calls the PC-Lint through the command line and executes detection according to the lnt file, and specifically comprises the following steps:

starting multiple threads, calling the PC-Lint by each thread through a command line, and detecting a source file;

waiting for the execution of all threads to be finished, and generating a checking result of the PC-Lint;

analyzing and generating a PC-Lint inspection result, and filtering false reports and useless results in the PC-Lint inspection result according to result filtering conditions in the configuration file to form a final inspection result;

and storing the final inspection result in an independent file by taking the project as a unit.

when the input parameters indicate that the inspection type is incremental inspection, a base line inspection result directory is appointed;

reading a baseline check result file from the baseline check result directory, and performing three-level indexing according to the project name, the file name and the error information to form a baseline index result;

matching the final inspection result with the baseline index result according to the project name, the file name and the error information, filtering out the matched information, and taking the result which is not filtered out as the final increment inspection result;

and saving the final increment check result in an independent file by taking the project as a unit.

The invention also provides a device for static code inspection, which comprises:

a configuration module to: adding a self-defined check filtering condition in the configuration file;

a map generation module to: acquiring input parameters, determining a source code file to be detected according to the input parameters and a configuration file, and generating mapping from an engineering name to a source code file list;

lnt a file generation module to: lnt files are generated according to the mapping from the project name to the source code file list;

an inspection module to: the PC-Lint is called through the command line, and detection is performed according to the lnt file.

On the basis of the above technical solution, the configuration module is specifically configured to:

On the basis of the above technical solution, the mapping generation module is specifically configured to:

On the basis of the above technical solution, the lnt file generating module is specifically configured to:

generating a general user-defined configuration;

Compared with the prior art, the invention has the advantages that:

the invention adopts a mode of self-defining checking filtering condition and automatic checking to automatically generate parameters suitable for PC-Lint in batch, conveniently checks a single source code file, efficiently filters invalid contents in a checking result and can effectively shorten the checking time. The invention can not only perform single source code file check but also perform incremental check. Meanwhile, the invention can call PC-Lint to carry out multithreading concurrent execution, further shorten the inspection time, promote the enthusiasm of encoding personnel for code static inspection, and further improve the software quality.

Drawings

FIG. 1 is a flowchart illustrating a method for static code checking according to an embodiment of the present invention;

FIG. 2 is a flowchart illustrating an exemplary process of checking a source code file according to the present invention;

FIG. 3 is a flow chart illustrating an inspection process according to an embodiment of the present invention;

FIG. 4 is a flowchart illustrating an exemplary process for checking a directory;

FIG. 5 is a flow chart illustrating the generation lnt of a file according to an embodiment of the present invention;

FIG. 6 is an example of a custom generated lnt file according to an embodiment of the present invention;

FIG. 7 is a flowchart illustrating a process of full-scale checking according to an embodiment of the present invention;

FIG. 8 is a flowchart illustrating an incremental check process according to an embodiment of the present invention;

fig. 9 is a flowchart illustrating an incremental check application scenario according to an embodiment of the present invention.

Detailed Description

Embodiments of the present invention will be described in further detail below with reference to the accompanying drawings.

Referring to fig. 1, an embodiment of the present invention provides a method for static checking of a code, including the following steps:

s1, adding self-defined examination filtering conditions in the configuration file;

s2, acquiring input parameters, determining a source code file to be detected according to the input parameters and the configuration file, and generating mapping from a project name to a source code file list;

s3, generating lnt files according to the mapping from the project names to the source code file list;

s4, calling PC-Lint through the command line, and executing detection according to lnt files.

The embodiment of the invention adopts a mode of self-defining checking filtering conditions and automatic checking to automatically generate parameters suitable for PC-Lint in batches, conveniently checks a single source code file, efficiently filters invalid contents in a checking result and can effectively shorten the checking time.

Preferably, the customized checking filter condition is embodied in the configuration file, and the beginning of a line in all the configuration files is equal; "begin then means annotated text. Adding a custom check filtering condition in the configuration file, specifically comprising the following steps:

(1) A source code exclusion condition is added. Txt is used to custom check the source code file that needs to be excluded, content example:

(ii) a (ii) a Codes not requiring checking, e.g. third-party libraries, automatically generated codes, etc

stdsoap2.cpp

stdsoap2.h

Each row represents a code file name that does not need to be checked.

The contents of this include: the codes of the third-party library, the codes automatically generated by the tool, historical legacy codes, other special codes and the like are unified for a development project or a person in a development department, and the complicated process of setting in the PC-Lint is simplified.

(2) Directory exclusion conditions are added. Txt is used to custom check source code or engineering files in the entire directory that need to be excluded, content examples:

(ii) a (ii) a Directories that do not require checking, e.g. third-party libraries, automatically generated code directories, etc

a/b/c/d

One directory can contain several or dozens of source code files, several or dozens of project files, subdirectories are arranged under the directory, the whole directory is excluded, all codes and projects under the directory and the subdirectories are not checked any more, exclusion cannot be set in the PC-Lint, the configuration files can be used for conveniently excluding, and the checking time is saved.

(3) And additionally arranging project elimination conditions. Txt is used to custom check the engineering files that need to be excluded, content example:

(ii) a (ii) a Projects not requiring inspection, e.g. third party libraries, automatically generated code, etc

sysinfo_stlp.vcproj

miniunz.vcproj

msmp_potsadapter_stlp.vcproj

msmp_cliadapter_stlp.vcproj

msmp_otnadapter_stlp.vcproj

msmp_product_f1kadapter_stlp.vcproj

msmp_product_otnadapter_stlp.vcproj

msmp_product_potsadapter_stlp.vcproj

unmnbi_pb_proto_stlp.vcproj

A project file may contain source code files for several directories. When the whole project is subjected to code static inspection, a plurality of third-party libraries and codes automatically generated by tools are usually available, the codes are relatively stable and do not need to be inspected and modified, but exclusion cannot be set in the PC-Lint, and the configuration file can be used for conveniently excluding the codes, so that the inspection time is saved.

(4) Result filtering conditions are added. Txt is used to define the keywords or error codes that need to be filtered in the inspection result, and the content example is as follows:

(ii) a (ii) a Note that: the following keywords are in units of whole lines, and if the pclin check result contains the keywords, the keywords are considered to be false reports, and are filtered out. The keywords are strictly classified into cases and cases, please copy directly

boost::serialization::singleton

boost::enable_shared_from_this

_foreach_col

_foreach_cur

_foreach_end

_foreach_continue

'BOOST_FOREACH

is non-trivial

(ii) a (ii) a The following numbers indicate the error ID to be filtered out

26; writing notes

611; writing notes

The false alarm content of the PC-Lint is very much, and particularly, the false alarm content is used for a third-party library (the code of the third-party library is not modified), a macro and the like; there are also many problems that do not require modification. If the results are displayed to the user, content interference and information confusion are easily caused, false reports in the inspection results and contents which do not need to be modified are filtered through the configuration, the information presented to the user is greatly reduced, and key problems can be directly hit.

Further, a method of automated inspection according to an embodiment of the present invention will be described. In order to realize automatic check, the command line version of the PC-Lint is used for checking, corresponding check conditions are generated according to the self-defined configuration file, parameters accepted by the PC-Lint are generated, the generated parameters are stored in a file with a suffix of lnt corresponding to the project name, and then the command line program calls and executes the parameters.

The command line calling instruction comprises the following steps:

1、"C:\*\lint-nt.exe"

2、-i"C:\*customize\lnt"

3、-i"C:\*\PC-lint\9.0\lnt"

4、-b-u"C:\*\pc-lint\*customize\std.lnt"env-vc9.lnt-vm-t4+linebuf+linebuf+linebuf

5、--uD:\*\*code_project\*code_project.lntD:\*\code_dir\msmpsavedb.cpp

description of the drawings: line 1 is an executable program line-nt.exe of the PC-line command line version, using an absolute path.

2 nd behavior user defined lnt file containing default configuration parameters for all project and engineering inspection;

behavior 3 contains the PC-Lint own lnt directory, using all lnt files therein as the default checking configuration;

line 4 indicates that custom std.lnt files are used;

line 5 shows that the lnt file generated using the custom configuration file is used to check the following source code file msmpsavedb.

After the command line execution is finished, the check result of msmpsavdb.

The calling method can conveniently carry out static check on a single source code file.

Preferably, referring to fig. 2, the process of checking a source code file includes:

101. in this scenario, when the system runs, the input parameter represents that one source code file is checked, and the source code file name and the specific path are specified;

102. firstly, judging whether the file is excluded or not according to a configuration file 'excclose _ src.txt', and if the file is required to be excluded, terminating the process;

103. if the source code does not need to be eliminated, the project where the source code is located can be found according to the path, and the mapping from the project name to the source code file is output for other subsequent processes.

Preferably, referring to fig. 3, the process of checking a project includes:

201. in the scene, when the system runs, the input parameter represents to check a project, and the project name and the specific path are specified;

202. determining whether the project is excluded according to the configuration file 'excclose _ project. txt', and if the project is required to be excluded, terminating the process;

203. if the source code files do not need to be eliminated, analyzing the project files, taking out all the source code files contained in the project, and eliminating the source code files according to the configuration file 'excclose _ src.txt';

204. and the rest source code files after the processing are the source code files to be checked, if the rest source code files are empty, the process is terminated, and if the rest source code files are not empty, the mapping from the project name to the source code files is output for other subsequent processes.

Preferably, referring to fig. 4, the process of checking a directory includes:

301. in this scenario, when the system runs, the input parameter represents to check a directory, and the name and specific path of the directory are specified;

302. judging whether the directory is excluded or not according to the configuration file 'excclose _ dir.txt', and if the directory needs to be excluded, terminating the process;

303. if the project is not required to be excluded, recursively acquiring all project files under the root directory, and then excluding the project according to the configuration file 'exclude _ project.txt'; analyzing the project file to obtain all source code files contained in the project, and eliminating the source code files according to a configuration file 'excclose _ src.txt';

304. and outputting the mapping from the project name to the source code file for use by other subsequent processes.

In a preferred embodiment, referring to fig. 5, the process of generating the custom lnt file includes:

401. the mapping from the project name output in the above steps to the source code file is the input data of the process. Lnt files are generated according to the mapping of project names to the source code file list, if there are a plurality of projects, the following steps are executed for a plurality of times in a circulating way:

402. generating a general custom configuration, such as "-si 4-sp4-D _ CPPRTTI", and the like;

403. analyzing source files in the engineering file to contain directories, wherein each source file contains a directory to generate a-i parameter; corresponding-i parameters are also generated for the system containment directory

404. Analyzing library containing directories in the engineering file, wherein each library containing directory generates a + libdir parameter

405. The source file list corresponding to the project name is written into the rearmost of the lnt file, lnt file is generated, and a complete lnt file example is shown in fig. 6.

As a preferred embodiment, referring to fig. 7, the process flow for performing a full-scale inspection includes:

501. initializing a code static checking system;

502. reading the configuration files and executing an initialization process;

503. carrying out system input parameter processing;

504. generating a mapping from the project name to the source code file list according to the flows of fig. 2, fig. 3 and fig. 4;

505. circularly starting an inspection thread by taking a project as a unit to perform concurrent processing;

506. calling the lnt file generator of FIG. 5 to generate a lnt file;

507. and (3) carrying out multithreading: calling PC-Lint through a command line by the automatic inspection method, and detecting a source file by each thread;

508. after all threads are executed, generating a checking result of the PC-Lint; and analyzing the inspection result, filtering the false alarm and useless result in the inspection result of the PC-Lint according to the configuration script' filter.

509. And the system operation is finished.

In the process, customized inspection is conveniently carried out by comprehensively applying the custom configuration script; the customized inspection condition is converted into the configuration which can be identified by PC-Lint by independently developing a custom lnt file generator; by means of multi-thread concurrent processing of multiple projects, inspection efficiency is improved; by further carrying out multi-thread concurrent inspection on a plurality of source code files of a single project, the inspection efficiency is further improved, the inspection time of one project is shortened, and the overall inspection time is also greatly shortened; by carrying out custom filtering on the inspection result, the final inspection result is more valuable, the enthusiasm of developers for carrying out static code inspection is promoted, and the improvement of software development quality is indirectly promoted.

As a preferred embodiment, referring to fig. 8, the processing flow of performing one increment check includes:

601. before the incremental inspection, a result of the full-scale inspection needs to be used as a baseline inspection result, and a result finally generated by the flow illustrated in fig. 7 can be used as a baseline inspection result.

602. Initializing a code static checking system, reading each introduced configuration file and executing an initialization process;

603. processing system input parameters, wherein the system input parameters indicate that the inspection type is incremental inspection, and a baseline inspection result directory is specified;

604. generating a mapping from the project name to the source code file list according to the flows of fig. 2, fig. 3 and fig. 4;

605. circularly starting an inspection thread by taking a project as a unit to perform concurrent processing;

606. calling the lnt file generator of FIG. 5 to generate a lnt file;

607. and (3) carrying out multithreading: calling PC-Lint through a command line by the automatic inspection method, and detecting a source file by each thread;

608. after all threads are executed, generating a checking result of the PC-Lint;

609. analyzing and checking results: firstly, carrying out first round of result screening, and filtering false reports and useless results in the checking result of the PC-Lint according to a configuration script' filter.

610. Reading a baseline check result file from a baseline check result directory, performing three-level indexing according to project names, file names, (error classification, error ID and error information), performing second-round result screening, matching in the three-level indexing according to the project names, the file names, (error classification, the error ID and the error information), and if matching is achieved, indicating that the result is the last existing result, filtering, so that the result which is not filtered is the final increment check result, and storing the increment check result in an independent file by taking a project as a unit.

611. And updating the increment result to a baseline check result file to form a baseline of the next increment check.

612. And the system operation is finished.

The user only needs to process the increment checking result, so that the information quantity is greatly reduced, the enthusiasm of developers for carrying out code static checking is facilitated, and the improvement of software development quality is indirectly promoted.

In a preferred embodiment, a baseline source code library is placed on the version manager at the time of development project initialization. The baseline source code is downloaded from the version manager to the local for development, and only the static inspection problem caused by adding or modifying the code is concerned.

Referring to fig. 9, the incremental check application scenario flow includes:

701. firstly, carrying out full-scale inspection on a project base line source code library, and issuing a base line inspection result to a server A;

702. carrying out coding development on the basis of a base line source code library, and simultaneously downloading a base line inspection result from a server A to the local;

703. performing incremental check on the developed code, and executing the incremental check flow described in fig. 7;

704. and obtaining an increment inspection result, only a new problem introduced by a newly added code needs to be modified, the influence of the previous legacy problem on the existing project is shielded, the enthusiasm of developers for carrying out code static inspection is promoted, and the improvement of software development quality is indirectly promoted.

The embodiment of the invention also provides a device for static code inspection, which comprises:

As a preferred embodiment, the configuration module is specifically configured to:

Preferably, the mapping generation module is specifically configured to:

the input parameters comprise a directory name to be tested, a source code file name or an engineering name and a corresponding specific path;

Preferably, the lnt file generating module is specifically configured to:

generating a general user-defined configuration;

As a preferred embodiment, the checking module is specifically configured to:

Further, the checking module is specifically further configured to:

It will be apparent to those skilled in the art that various changes and modifications may be made in the present invention without departing from the spirit and scope of the invention. Thus, if such modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include such modifications and variations.

Claims

1. A method for static checking of a code, comprising the steps of:

adding a self-defined check filtering condition in the configuration file;

2. The method of claim 1, wherein adding a custom check filter condition to the configuration file comprises the steps of:

3. The method of claim 2, wherein the steps of obtaining input parameters, determining a source code file to be detected according to the input parameters and a configuration file, and generating a mapping from a project name to a source code file list comprise:

4. The method as claimed in claim 3, wherein the lnt file is generated according to the mapping of the project name to the source code file list, comprising the following steps:

generating a general user-defined configuration;

5. The method of claim 4, wherein the PC-Lint is invoked by a command line to perform the detection according to the lnt file, comprising the steps of:

6. The method of claim 5, wherein the PC-Lint is invoked by a command line to perform the detection according to the lnt file, further comprising the steps of:

7. An apparatus for static checking of code, comprising:

8. The device of claim 7, wherein the configuration module is specifically configured to:

9. The device of claim 8, wherein the map generation module is specifically configured to:

10. The device of claim 9, wherein the lnt file generation module is specifically configured to:

generating a general user-defined configuration;