Code defect identification method, electronic device and storage medium

Abstract

The present application provides a method for identifying code defects, an electronic device, and a storage medium, and relates to the field of computer technology. In the method, for a source code, a first code is obtained by removing or replacing redundant information in the source code. A defect identifier is generated for the defective code statement in the first code according to the file name of the source code, the defect type corresponding to the defective code statement in the first code, the defective code statement in the first code, and the context content of the defective code statement in the first code. In this way, a defect identifier that can uniquely identify the defective code statement can be generated for the defective code statement in the first code, and defective codes that repeatedly issue alarms can be identified, thereby achieving the technical effect of reducing the false alarm rate.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computer technology, and in particular to a method for identifying code defects, an electronic device, and a storage medium. Background Art

[0002] It is common in today's computer industry to use static defect checking tools to assist in discovering potential vulnerabilities and code standard issues in the code.

[0003] Static defect checking finds security risks and non-standard code in the source design code without the need for compilation, and provides a list of defect results. Software developers use some open source tools or commercial tools to check the design code, such as Coverity, Infer, and CodeChecker, and then audit the defect results generated by the tools.

[0004] Conventional static defect checking tools generate a large number of false positives, which brings great trouble to developers. Summary of the invention

[0005] The embodiments of the present application provide a code defect identification method, an electronic device, and a storage medium, which are used to solve the technical problem that conventional static defect inspection tools may generate a large number of false alarms.

[0006] To achieve the above objectives, the embodiments of the present application adopt the following technical solutions:

[0007] In a first aspect, a method for identifying a code defect is provided, the method comprising:

[0008] Redundant information in the source code is removed or replaced to obtain a first code; wherein the redundant information includes grammatical format elements, identifiers and character strings in the source code, and the first code includes one or more first defective code statements and one or more first non-defective code statements.

[0009] A defect identifier is generated for the first defective code statement according to the file name of the source code, the defect type corresponding to the first defective code statement, the first defective code statement and the context content of the first defective code statement; wherein the defect identifier is used to uniquely identify the first defective code statement.

[0010] The context content of the first defective code statement includes: the first m lines of code statements adjacent to the first defective code statement in the first code, and / or the last n lines of code statements adjacent to the first defective code statement in the first code, where m and n are not zero at the same time.

[0011] In this way, by removing or replacing the redundant information in the source code to obtain the first code, the change of the defect identification caused by the change of the redundant information can be avoided. Since the file name of the source code used to generate the defect identification, the defect type of the first defect code statement, the first defect code statement, and the context content of the first defect code statement are only related to the source code itself or the first code itself, and do not include components coupled with the static inspection tool, the defect identification can uniquely identify the defect code statement. Therefore, the code defect identification method provided in the embodiment of the present application is not coupled with the static inspection tool, and can be used alone as a static inspection tool, and can also be compatible with other static inspection tools to manage the detection reports of multiple static inspection tools, thereby solving the technical problem that conventional static defect inspection tools will generate a large number of false alarms.

[0012] In a possible implementation manner of the first aspect, the method includes:

[0013] For the source code, redundant information in the source code is removed or replaced to obtain the first code. A defect identifier is generated for the defective code statement in the first code according to the file name of the source code, the defect type corresponding to the defective code statement in the first code, the defective code statement in the first code, and the context content of the defective code statement in the first code.

[0014] Wherein, the redundant information includes grammatical format elements, identifiers and strings in the source code, and the grammatical format elements include at least: spaces in each code statement in the source code, blank lines between code statements, line breaks in each code statement, comments on code statements, scopes of code statements, and capital letters in code statements. The first code includes one or more first defective code statements and one or more first non-defective code statements. The defect identifier can be used to uniquely identify the first defective code statement. Wherein, the context content of the defective code statement in the first code includes: the first m lines of code statements adjacent to the defective code statement in the first code, the next n lines of code statements adjacent to the first code, or the first m lines of code statements adjacent to the defective code statement in the first code and the next n lines of code statements adjacent to the first code. m and n are not zero at the same time.

[0015] In this way, by removing or replacing the redundant information in the source code to obtain the first code, the change of the defect identification caused by the change of the redundant information can be avoided. Since the file name of the source code used to generate the defect identification, the defect type of the first defect code statement, the first defect code statement, and the context content of the first defect code statement are only related to the source code itself or the first code itself, and do not include components coupled with the static inspection tool, the defect identification can uniquely identify the defect code statement. Therefore, the code defect identification method provided in the embodiment of the present application is not coupled with the static inspection tool, and can be used alone as a static inspection tool, and can also be compatible with other static inspection tools to manage the detection reports of multiple static inspection tools, thereby solving the technical problem that conventional static defect inspection tools will generate a large number of false alarms.

[0016] In a possible implementation manner of the first aspect, before generating a defect identifier for the defective code statement in the first code according to the file name of the source code, the defect type corresponding to the defective code statement in the first code, the defective code statement in the first code, and the context content of the defective code statement in the first code, the method further includes:

[0017] A detection report is obtained by performing static checking on the source code using multiple static checking tools, wherein the detection report includes a file name of the source code, a defect type of a defective code statement in the source code, and a line number of the defective code statement in the source code.

[0018] In the process of removing or replacing redundant information in the source code to obtain the first code, a mapping relationship between the line number of each code statement in the first code and the line number of each code statement in the source code is obtained.

[0019] The defective code statement in the first code and the defect type of the defective code statement in the first code are determined through a mapping relationship and the line number of the defective code statement in the source code; when there is a mapping relationship between the line number of a defective code statement in the first code and the line number of a defective code statement in the source code, the defect type of the defective code statement in the first code is the same as the defect type of the defective code statement in the source code.

[0020] In this way, multiple first detection reports can be obtained by performing static checking on the source code through multiple conventional static checking tools, and the file name of the source code, the defect type of the second defective code statement in the source code, and the line number of the second defective code statement can be obtained. Then, the first defective code statement in the first code and the defect type of the first defective code statement can be obtained according to the mapping relationship. The context content of the first defective code statement can be obtained in combination with the code defect identification method of the embodiment of the present application to generate a defect identification, which is helpful for unified management of the detection reports of conventional static checking tools.

[0021] In a possible implementation manner of the first aspect, before generating a defect identifier for the defective code statement in the first code according to the file name of the source code, the defect type corresponding to the defective code statement in the first code, the defective code statement in the first code, and the context content of the defective code statement in the first code, the method further includes:

[0022] Obtain the line number of the defective code statement in the first code, the first m lines of code statements adjacent to the defective code statement in the first code include the m lines of code statements before the defective code statement and adjacent to the defective code statement, and the last n lines of code statements adjacent to the defective code statement in the first code include the n lines of code statements after the defective code statement and adjacent to the defective code statement.

[0023] In this way, the server can locate the position of the first defective code statement in the first code by obtaining the line number of the first defective code statement, and search for the context content of the first defective code statement m lines forward and / or n lines backward from the position of the first defective code statement in the first code, thereby helping to locate the context content of the first defective code statement.

[0024] In a possible implementation manner of the first aspect, obtaining a line number of a first defective code statement includes:

[0025] Obtain the line number of the defective code statement in the source code. Obtain the line number of the defective code statement in the first code corresponding to the line number of the defective code statement in the source code through the mapping relationship between the line number of each code statement in the first code and the line number of each code statement in the source code.

[0026] In this way, the server can obtain the line number of the defective code statement in the first code that has a mapping relationship with the line number of the defective code statement in the source code according to the line number of the defective code statement in the source code through the mapping relationship between the line number of each code statement in the first code and the line number of each code statement in the source code.

[0027] In a possible implementation of the first aspect, the first m lines of code statements are adjacent to the defective code statement in the first code, are before the defective code statement in the first code, and are included in the declaration position of the code element where the defective code statement in the first code is located. The last n lines of code statements are adjacent to the defective code statement in the first code, are after the defective code statement in the first code, and are included in the declaration position of the code element where the defective code statement in the first code is located.

[0028] In this way, since the defect identifier is generated based on the defective code statement in the first code included in the declaration position of the code element where the first defective code statement is located and the context content of the defective code statement in the first code, the defect identifier is not affected by the first code outside the declaration position of the code element where the defective code statement in the first code is located.

[0029] In a possible implementation manner of the first aspect, the source code includes one or more defective code statements; before generating a defect identifier for the defective code statement in the first code according to a file name of the source code, a defect type corresponding to the defective code statement in the first code, the defective code statement in the first code, and context content of the defective code statement in the first code, the method further includes:

[0030] The source code is parsed to obtain a grammatical analysis result, which indicates the declaration position of the code element where the line number of the defective code statement in the source code is located. The line number of the declaration position of the code element where the line number of the defective code statement in the first code is located in the first code is determined through a mapping relationship between the line number of each code statement in the first code and the line number of each code statement in the source code.

[0031] In this way, by performing syntax analysis on the source code, the declaration position of the code element where the line number of the defective code statement in the source code is located is obtained, and then the declaration position of the code element where the line number of the defective code statement in the first code is obtained, which helps to ensure that the context content of the defective code statement in the first code does not exceed the declaration position of the code element of the defective code statement in the first code, thereby helping to avoid the influence of the declaration position of the code element on the defect identification.

[0032] In a possible implementation manner of the first aspect, after generating a defect identifier for the defective code statement in the first code according to the file name of the source code, the defect type corresponding to the defective code statement in the first code, the defective code statement in the first code, and the context content of the defective code statement in the first code, the method further includes:

[0033] In the case where there is a mapping relationship between the line number of the defective code statement in the first code and the line number of the defective code statement in the source code, the defect identifier of the defective code statement in the first code is added to the defective code statement in the source code. In the case where the defective code statements in the source code have the same defect identifier, it means that the defective code statements in the source code are repeated, and the defective code statements in the source code in the first detection report are deduplicated.

[0034] In this way, the code defect identification method provided by the embodiment of the present application can perform unified analysis and management on the first detection reports of multiple static inspection tools, identify and deduplicate defective code statements in the source code repeated in the first detection report, and solve the technical problem that conventional static defect inspection tools will generate a large number of false alarms.

[0035] In a possible implementation manner of the first aspect, before generating a defect identifier for the defective code statement in the first code according to the file name of the source code, the defect type corresponding to the defective code statement in the first code, the defective code statement in the first code, and the context content of the defective code statement in the first code, the method further includes:

[0036] According to the detection report of the existing static inspection tool, the file name of the first code, the defect type and line number of the defective code statement in the first code are obtained, and the file name of the first code is the same as the file name of the source code.

[0037] In this way, based on the file name of the first code in the detection report and the defect type of the defective code statement in the first code, there is no need to obtain the mapping relationship between the line number of each code statement in the first code and the line number of each code statement in the source code. The defect identifier can be generated by combining the defective code statement in the first code and the context content of the defective code statement in the first code, which helps to easily realize the generation of defect identifiers.

[0038] In a possible implementation manner of the first aspect, removing or replacing redundant information in a source code to obtain a first code includes:

[0039] The static checking tool installed on the server directly obtains the file name of the first code and the defect type of the defective code statement in the first code in the process of removing or replacing redundant information from the source code to obtain the first code. The file name of the first code is the same as the file name of the source code.

[0040] In this way, the static checking tool provided by the embodiment of the present application can directly process the source code to obtain the first code, the file name of the first code and the defect type corresponding to the defective code statement in the first code. There is no need to obtain the mapping relationship between the line number of each code statement in the first code and the line number of each code statement in the source code. The defect identifier can be generated by combining the defective code statement in the first code and the context content of the defective code statement in the first code, which helps to easily realize the generation of defect identifiers.

[0041] In a possible implementation of the first aspect, the grammatical format elements include at least: spaces in each code statement in the source code, blank lines between code statements, line breaks in each code statement, comments on code statements, and scopes of code statements.

[0042] In this way, by removing or replacing the first code generation defect identifier of the syntax format element, the change of the defect identifier caused by the change of blank lines, line breaks, spaces, comments, and scope can be avoided.

[0043] In a second aspect, the present application provides an electronic device, which includes at least a memory and one or more processors; the memory is used to store computer instructions, and when one or more processors execute the computer instructions, the electronic device executes the method described in any one of the first aspects above.

[0044] In a third aspect, the present application provides a computer-readable storage medium, which stores computer instructions or programs. When the computer instructions or programs are run on a computer, the method of any one of the above-mentioned first aspects is executed.

[0045] In a fourth aspect, the present application provides a computer program product, which includes computer instructions; when part or all of the computer instructions are run on a computer, the method of any one of the above-mentioned first aspects is executed. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 A schematic diagram of a source code including defects;

[0047] Figure 2 A defect detection report diagram obtained by statically checking the above source code by related technologies;

[0048] Figure 3 A structural block diagram of a server provided in an embodiment of the present application;

[0049] Figure 4 Schematic diagram of the method for identifying code defects provided in the embodiment of the present application Figure 1 ;

[0050] Figure 5 Preprocessing process of source code provided in the embodiment of the present application Figure 1 ;

[0051] Figure 6 Preprocessing process of source code provided in the embodiment of the present application Figure 2 ;

[0052] Figure 7 Schematic diagram of the method for identifying code defects provided in the embodiment of the present application Figure 2 ;

[0053] Figure 8 It is a schematic diagram of the syntax format elements in the source code;

[0054] Fig. 9is a schematic diagram of the second code;

[0055] Fig.10 A schematic diagram of the declaration position of the code element where the second defective code statement is located;

[0056] Fig.11 is a schematic diagram of the third code;

[0057] Fig.12 A schematic diagram of strings and identifiers in the third code;

[0058] Fig.13 is a schematic diagram of the first code;

[0059] Fig.14 Schematic diagram of the method for identifying code defects provided in the embodiment of the present application Figure 3 ;

[0060] Fig.15 Schematic diagram of the method for identifying code defects provided in the embodiment of the present application Figure 4 . DETAILED DESCRIPTION

[0061] The technical solution in the embodiment of the present application will be described below in conjunction with the drawings in the embodiment of the present application. In the description of the embodiment of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone.

[0062] In the following, the terms "first" and "second" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features. In the description of this embodiment, unless otherwise specified, "plurality" means two or more.

[0063] Before introducing specific embodiments, in order to facilitate understanding, some descriptions of concepts related to the embodiments of the present application are given by way of example for reference.

[0064] Hash: It can also be called hash or hashing. It means that an input of any length (also called pre-image) is transformed into an output of fixed length through a hash algorithm. The output is the hash value. This conversion is a compression mapping, that is, the space of hash values ​​is usually much smaller than the space of inputs. Different inputs may hash to the same output, so it is impossible to determine the unique input value from the hash value.

[0065] Code element: refers to various components defined in a programming language, such as variables, functions, classes, modules, etc. Declaration location refers to the specific location of a code element in a source code file.

[0066] Identification calculation component: used to calculate the content of the defect identification. When the defect identification is expressed in the form of a hash, the identification calculation component is the input value of the hash.

[0067] When the code is statically checked using a static checking tool, the code defects of the code to be checked can be directly found by statically scanning the code, without starting the dynamic running software to run the code to be checked. Therefore, static checking is a common technical means to intercept software code defects in advance and ensure software quality. Before the software goes online, a variety of static checking tools need to be used to statically check the code. For static checking defect management systems in the continuous integration or release process of large-scale software projects, defect identifiers are used to uniquely identify a code defect.

[0068] It is understood that a file output stream is a class in the Java language that is used to write data to a file. To avoid resource leaks, ensure that the file output stream is released in a timely manner after use. For example, use a try-with-resources statement or close the file output stream in a finally block. If the file output stream is not released, a resource leak may occur because the file output stream occupies the file description of the operating system or causes incomplete or corrupted data.

[0069] Figure 1 is a schematic diagram of a source code that includes defects. Figure 1 As shown, in the first example, the 14th line of the source code applies for a file output stream resource. When the file where the source code is located can be accessed normally, since the source code only applies for the file output stream resource in the 14th line, and the resource is not released in the subsequent source code, there is a resource leakage defect in the 14th line of the source code. The code in the 14th line of the source code can be called a defective code statement.

[0070] Figure 2 The defect detection report diagram is obtained by statically checking the above source code in the related technology. Figure 2As shown, the related technology performs static inspection on the above source code to obtain a detection report including at least one defect alarm, the defect alarm content includes but is not limited to the defect type (bug type), defect description (qualifier), danger level (severity), alarm line number (line), the file name (file) where the source code is located, and the defect identifier represented by hash (hash). The alarm line number is the line number of the defective code statement in the source code. In the first example, the alarm line number is line 14.

[0071] The defect identifier in the defect detection report, which is represented by a hash, uniquely identifies the resource leakage defect in the above source code. When multiple static checking tools are used to perform static checking on the same source code, since different static checking tools do not uniformly describe defects and determine the risk level for the same source code, the defect detection reports generated by different static checking tools for the same source code are not compatible with each other, and thus it is impossible to deduplicate the defect detection reports generated by different static checking tools.

[0072] In the related art, when the static checking tool generates defect identifiers only for defective code statements, if there are two or more defects in the same line of defective code statements, the defect identifiers corresponding to the two or more defects are the same, and the defect identifiers are not unique, so the prior art has a technical problem of being unable to uniquely identify defects. For example, the defective code statement in the first example above is the code on line 14. When there are two or more defects on line 14, the defect identifiers corresponding to the two or more defects are only generated for the code on line 14. The defect identifiers corresponding to the two or more defects are repeated, and the defect identifier cannot uniquely identify any defect on line 14.

[0073] In addition, when the same static checking tool is used to perform static checking on the same section of source code, if the developer modifies the syntax format elements of the source code, the defect identifier may be changed due to the change in the syntax format elements of the source code (such as deleting spaces or blank lines), which may cause the static checking tool to issue duplicate defect warnings for the same defect and generate different defect identifiers.

[0074] In order to solve the above technical problems, an embodiment of the present application provides a method for identifying code defects, which can prevent the modification of code syntax format elements from causing changes in defect identification by preprocessing the source code, removing or replacing the syntax format elements, strings and identifiers in the source code, and generating a unique defect identification based on the identification calculation components related to the source code itself, and the identification calculation components related to the source code itself do not include components coupled with static inspection tools. The method for identifying code defects provided by the present application can be applied to a static inspection tool alone to generate defect identification for source code, and can also be compatible with other static inspection tools, and manage the detection reports of multiple static inspection tools, thereby solving the technical problem that conventional static defect inspection tools will generate a large number of false positives.

[0075] The code defect identification method provided in the embodiment of the present application can be applied to a server to uniformly manage defect detection reports of multiple static checking tools, and can also be used as a static checking tool alone to identify defects in source code. Figure 3 The structure block diagram of a server provided in the embodiment of the present application is as follows. The server is described in detail. It is understood that the structure illustrated in the embodiment of the present application does not constitute a specific limitation on the server. In other embodiments, the server may include Figure 3 More or fewer components, or combining some components, or splitting some components, or different component arrangements. The components shown in the figure can be implemented in hardware, software, or a combination of software and hardware.

[0076] like Figure 3 As shown, the server may include a processor 110, a memory 120 and a communication module 130. The processor 110 may be used to read and execute computer-readable instructions. Optionally, the processor 110 may also include a controller, an arithmetic unit and a register. Among them, the controller is mainly responsible for decoding instructions and issuing control signals for operations corresponding to the instructions. The arithmetic unit is mainly responsible for saving register operands and intermediate operation results temporarily stored during the execution of instructions. The register is a high-speed storage component with limited storage capacity, which can be used to temporarily store instructions, data and addresses.

[0077] In a specific implementation, the hardware architecture of the processor 110 may be an application specific integrated circuit (ASIC) architecture, a microprocessor without interlocked piped stages (MIPS) architecture, an ARM (advanced RISC machines) architecture, or a network processor (NP) architecture, etc. In some embodiments, the processor 110 may be used to remove or replace redundant information in the source code to obtain the first code. In some embodiments, the processor 110 may be used to generate a defect identifier for a defective code statement based on the file name of the source code, the defect type corresponding to the defective code statement, the defective code statement, and the contextual content of the defective code statement.

[0078] The memory 120 is coupled to the processor 110 and is used to store various software programs and / or multiple sets of instructions. In the embodiment of the present application, the data storage method of the server can be integrated into a processor of the server for implementation, or it can be stored in the memory of the server in the form of program code, and a processor of the server calls the code stored in the memory of the server to execute the above method.

[0079] In a specific implementation, the memory 120 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more disk storage devices, flash memory devices or other non-volatile solid-state storage devices. The memory 120 may store an operating system, such as uCOS, VxWorks, RTLinux and other embedded operating systems. In some embodiments, the memory 120 may be used to store source code, may be used to store the first code, and may also be used to store defect identification.

[0080] The communication module 130 can be used to establish a communication connection between the server and other communication terminals through the network, and to send and receive data through the network. For example, the server establishes a connection with the electronic device through the communication module 130 to facilitate the transmission of subsequent instructions. In some embodiments, the communication module 130 can be used to receive the source code, and can also be used to send the first code to the client, and can also be used to send the defect identification to the client. In some embodiments, the communication module 130 can also display the defect identification to the user through a visual interface.

[0081] It is to be understood that the structure illustrated in this embodiment does not constitute a specific limitation on the server. In other embodiments, the server may include more or fewer components than shown in the figure, or combine some components, or split some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0082] The following is a detailed introduction to the code defect identification method provided by the present application with reference to the accompanying drawings and examples.

[0083] Figure 4 Schematic diagram of the method for identifying code defects provided in the embodiment of the present application Figure 1 .like Figure 4 As shown, the method for identifying code defects provided in the embodiment of the present application is applied to a server, and includes:

[0084] Step 401: The server removes or replaces redundant information in the source code to obtain a first code.

[0085] The redundant information includes syntax format elements, identifiers and character strings in the source code, and the first code includes one or more first defective code statements and one or more first non-defective code statements. The first defective code statement may be any defective code statement in the first code.

[0086] In a possible implementation, the syntax format elements include at least: spaces in each code statement in the source code, blank lines between code statements, line breaks in each code statement, comments on code statements, scopes of code statements, and uppercase letters in code statements. Replacing uppercase letters in code statements may be replacing uppercase letters with corresponding lowercase letters. A string may refer to a string between double quotes in the source code.

[0087] It should be noted that the first code is obtained by preprocessing the source code to remove or replace redundant information in the source code. The preprocessing of the source code may include a first preprocessing, a second preprocessing and / or a third preprocessing. The first preprocessing may be to remove or replace the grammatical format elements in the redundant information, the second preprocessing may be to remove or replace irrelevant code elements in the redundant information, and the irrelevant code elements are code elements that are irrelevant to the code elements where the defective code statements are located. The third preprocessing may be to remove or replace the strings and identifiers in the redundant information. The embodiment of the present application does not further limit the order of the first preprocessing, the second preprocessing, and the third preprocessing. The process of preprocessing the source code is described in detail below and will not be repeated here.

[0088] For example, Figure 5 Preprocessing process of source code provided in the embodiment of the present application Figure 1 , Figure 6 Preprocessing process of source code provided in the embodiment of the present application Figure 2 .

[0089] See also Figure 5In a first possible implementation, a first preprocessing is performed on the source code to obtain a second code, a second preprocessing is performed on the second code to obtain a third code, and a third preprocessing is performed on the third code to obtain the first code.

[0090] See also Figure 6 In a second possible implementation, the source code is subjected to a third preprocessing to obtain a second code, and the second code is subjected to a first preprocessing to obtain a first code.

[0091] After detecting the existence of defective code statements, developers may modify the source code. By removing or replacing redundant information, changes in defect identification caused by changes in grammatical format elements, irrelevant code elements, strings, and identifiers can be avoided. In an embodiment of the present application, removing or replacing redundant information can help reduce the probability of issuing repeated alarms for the same defective code statement, thereby helping to reduce the probability of generating different defect identifications for the same defect.

[0092] Step 402: The server generates a defect identifier for the first defective code statement according to the file name of the source code, the defect type of the first defective code statement, the first defective code statement, and the context content of the first defective code statement.

[0093] In the embodiment of the present application, step 402 may be executed for each defective code statement in the first code to generate a defect identifier for the defective code statement. The defect identifier is used to uniquely identify the first defective code statement.

[0094] In one implementation, the context content of the first defective code statement may include: first m lines of code statements adjacent to the first defective code statement in the first code.

[0095] In another implementation, the context content of the first defective code statement may include: the next n lines of code statements adjacent to the first defective code statement in the first code.

[0096] In another implementation, the context content of the first defective code statement may include: the first m lines of code statements adjacent to the first defective code statement in the first code and the last n lines of code statements adjacent to the first defective code statement in the first code.

[0097] It should be noted that the above m and n are not zero at the same time.

[0098] Exemplarily, the defect type corresponding to the first defect code statement may be a resource leakage defect, a null pointer exception defect, a buffer overflow defect, or an index out-of-bounds defect. This application does not further limit the defect type.

[0099] In the related art, defect identifiers are generated only for defective code statements in the source code. Therefore, when there are two or more defects in the first defective code statement, the defect identifier is not unique, and when redundant information in the source code changes, repeated alarms are issued for the same defect and different defect identifiers are generated.

[0100] The embodiment of the present application generates a defect identifier through the first defect code statement in the first code and the context content of the first defect code statement. Since the first code is a source code that removes or replaces redundant information, even if the redundant information in the source code changes, the embodiment of the present application will not issue repeated defect warnings or generate different defect identifiers for the same defect. Since the embodiment of the present application generates a defect identifier based on the first defect code statement and the context content of the first defect code statement, even if there are two or more defects in the first defect code statement, different context contents corresponding to different defects can be used to generate a defect identifier that can uniquely identify the defect.

[0101] In the embodiment of the present application, the server can manage one or more detection reports of one or more static inspection tools according to the defect identification.

[0102] In some embodiments, the server may obtain detection reports (such as first detection reports) of the source code respectively produced by one or more static inspection tools, wherein each static inspection tool performs static inspection on the source code respectively and may obtain a first detection report.

[0103] It should be noted that the above-mentioned multiple static checking tools are existing static checking tools. For the specific methods of using these static checking tools to perform static checking on the source code, please refer to the introduction of conventional technologies and will not be elaborated here. The detection report includes defect warnings generated for one or more code defects. The defect warnings include but are not limited to the following fields and corresponding field values: defect type, defect description, hazard level, second defect code statement, line number where the second defect code statement is located, source code file name and / or first defect identifier. The first defect identifier is the defect identifier generated by the static checking tool.

[0104] It should be noted that the file name of the source code refers to the name of the file where the source code is located. The second defective code statement is a code statement with defects in the source code. The defect type of the second defective code statement can refer to the description of the defect type of the first defective code statement above, and will not be repeated here.

[0105] Because the multiple static inspection tools are different, the multiple first inspection reports obtained are also different. For example, the fields and corresponding field values ​​included in the defect alarms in different first inspection reports may be different.

[0106] Specifically, the server manages the first detection report according to the defect identifier, and may establish a mapping relationship between the defect identifier obtained according to step 402 and the defect alarm. When there are multiple defect alarms corresponding to one defect identifier, the multiple defect alarms in the detection report are repeated, and the multiple repeated defect alarms are deduplicated.

[0107] The embodiment of the present application manages the first detection report generated by the static inspection tool for the source code, and can obtain the first detection report after the defect alarm is deduplicated. The developer can repair the defect in the source code according to the first detection report after the defect alarm is deduplicated, thereby reducing the false alarm rate of the defect alarm.

[0108] In this way, by removing or replacing the redundant information in the source code to obtain the first code, the change of the defect identification caused by the change of the redundant information can be avoided. Since the file name of the source code used to generate the defect identification, the defect type of the first defect code statement, the first defect code statement, and the context content of the first defect code statement are only related to the source code itself or the first code itself, and do not include components coupled with the static inspection tool, the defect identification can uniquely identify the defect code statement. Therefore, the code defect identification method provided in the embodiment of the present application is not coupled with the static inspection tool, and can be used alone as a static inspection tool, and can also be compatible with other static inspection tools to manage the detection reports of multiple static inspection tools, thereby solving the technical problem that conventional static defect inspection tools will generate a large number of false alarms.

[0109] In the embodiment of the present application, the server can obtain a mapping relationship between the line number of each code statement in the first code and the line number of each code statement in the source code during the process of executing step 401 to remove redundant information of the source code.

[0110] In this way, the server can match the second defect code in each first detection report with each code statement in the first code based on the mapping relationship, so as to determine the first defect code statement, the defect type and line number of the first defect code statement, etc.

[0111] Specifically, Figure 7 Schematic diagram of the method for identifying code defects provided in the embodiment of the present application Figure 2 ,like Figure 7 As shown, before the above step 402, the method of the embodiment of the present application may further include steps 701 to 703:

[0112] Step 701: The server obtains multiple first detection reports of source code.

[0113] Among them, the multiple first detection reports are obtained by using multiple static inspection tools to perform static inspection on the source code respectively; the first detection report may include the file name of the source code, the defect type of the second defective code statement, and the line number of the second defective code statement.

[0114] Step 702: in the process of removing or replacing redundant information in the source code to obtain the first code, the server obtains a mapping relationship between the line number of each code statement in the first code and the line number of each code statement in the source code.

[0115] It can be understood that the mapping relationship between the line number of each code statement in the first code and the line number of each code statement in the source code can be that the line number of each code statement in multiple lines of source code corresponds to the line number of each code statement in one line of the first code in the first code, or the line number of each code statement in one line of source code corresponds to the line number of each code statement in one line of the first code in the first code, or the line number of each code statement in one line of source code corresponds to the line number of each code statement in one line of the first code in the first code, and the line number of each code statement in one line of source code corresponds to the line number of each code statement in multiple lines of the first code in the first code. The mapping relationship is not further limited in the present application.

[0116] Step 703: The server determines the first defective code statement in the first code and the defect type of the first defective code statement through the mapping relationship and the line number of the second defective code statement; wherein the defect type of the first defective code statement is the same as the defect type of the second defective code statement corresponding to the line number having a mapping relationship with the line number of the first defective code statement.

[0117] It can be understood that when there is a mapping relationship between the line number of a defective code statement in the first code and the line number of a defective code statement in the source code, the defect type of the defective code statement in the first code is the same as the defect type of the defective code statement in the source code.

[0118] In this way, multiple first detection reports can be obtained by performing static checking on the source code through multiple conventional static checking tools, and the file name of the source code, the defect type of the second defective code statement in the source code, and the line number of the second defective code statement can be obtained. Then, the first defective code statement in the first code and the defect type of the first defective code statement can be obtained according to the mapping relationship. The context content of the first defective code statement can be obtained in combination with the code defect identification method of the embodiment of the present application to generate a defect identification, which is helpful for unified management of the detection reports of conventional static checking tools.

[0119] In the embodiment of the present application, the server may also obtain the line number of the first defective code statement before executing step 402, and the context content of the first defective code statement may be located through the line number of the first defective code statement.

[0120] In this way, the server can search forward or backward for the context content of the first defective code statement according to the line number of the first defective code statement.

[0121] Specifically, before the above step 402, the method of the embodiment of the present application may further include the following step 1:

[0122] Step 1: The server obtains the line number of the first defective code statement; the line number of the first defective code statement is the line number of the first defective code statement in the first code. The server obtains the context content of the first defective code statement according to the line number of the first defective code statement.

[0123] The context content of the first defective code statement may include the first m lines of code statements and / or the last n lines of code statements. The first m lines of code statements include the m lines of code statements adjacent to the line number of the first defective code statement, and the last n lines of code statements include the n lines of code statements adjacent to the line number of the first defective code statement.

[0124] Wherein, m and n are both natural numbers, and m and n are not both zero. Through the mapping relationship and the line number of the second defective code statement, the line number of the first defective code statement having a mapping relationship with the line number of the second defective code statement can be obtained.

[0125] In this way, the server can locate the position of the first defective code statement in the first code by obtaining the line number of the first defective code statement, and search for the context content of the first defective code statement m lines forward and / or n lines backward from the position of the first defective code statement in the first code, thereby helping to locate the context content of the first defective code statement.

[0126] In an embodiment of the present application, the first m lines of code statements are adjacent to the first defective code statement, are before the first defective code statement, and are included in the declaration position of the code element where the first defective code statement is located; the last n lines of code statements are adjacent to the first defective code statement, are after the first defective code statement, and are included in the declaration position of the code element where the first defective code statement is located.

[0127] Specifically, the first m lines of code statements are included in the declaration position of the code element where the first defective code statement is located, that is, m is less than or equal to the number of lines of code statements located before the first defective code statement in the declaration position of the code element where the first defective code statement is located. The last n lines of code statements are included in the declaration position of the code element where the first defective code statement is located, that is, n is less than or equal to the number of lines of code statements located after the first defective code statement in the declaration position of the code element where the first defective code statement is located.

[0128] In this way, since the defect identifier is generated based on the first defect code statement included in the declaration position of the code element where the first defect code statement is located and the context content of the first defect code statement, the defect identifier is not affected by the first code outside the declaration position of the code element where the first defect code statement is located.

[0129] In the embodiment of the present application, the server involved in the above step 1 obtains the line number of the first defective code statement, including:

[0130] The server obtains the line number of the second defective code statement; the line number of the second defective code statement is the line number of the second defective code statement in the source code. The server obtains the line number of the first defective code statement corresponding to the line number of the second defective code statement through the mapping relationship between the line number of each code statement in the first code and the line number of each code statement in the source code.

[0131] In this way, the server can obtain the line number of the first defective code statement having a mapping relationship with the line number of the second defective code statement according to the line number of the second defective code statement through the mapping relationship between the line numbers of each code statement in the first code and the line numbers of each code statement in the source code.

[0132] In an embodiment of the present application, before executing step 402, the server can add a defect identifier to the second defective code statement according to the mapping relationship, perform grammatical analysis on the source code, and obtain a grammatical analysis result, which indicates the declaration position of the code element where the line number of the defective code statement in the source code is located. The line number of the declaration position of the code element where the line number of the defective code statement in the first code is located in the first code is determined through the mapping relationship between the line number of each code statement in the first code in the first code and the line number of each code statement in the source code in the source code.

[0133] In this way, the server can obtain the declaration position of the code element where the line number of the second defective code statement is located by performing syntax analysis on the source code, and then obtain the declaration position of the code element where the line number of the first defective code statement is located.

[0134] Specifically, before step 402, the following steps 1 and 2 are also included:

[0135] Step 1: The server performs syntax analysis on the source code to obtain syntax analysis results.

[0136] Among them, the syntax analysis result indicates the declaration position of the code element where the line number of the second defective code statement is located. There are many ways to perform syntax analysis on the source code. For example, the source code can be analyzed by a parsing function (i.e., Parse() function). The syntax analysis result can be an abstract syntax tree (AST). The method for determining the declaration position of the code element where the line number of the second defective code statement is located can be to use a method definition function (i.e., GetMethodDef() function) to find the declaration position of the code element where the line number of the second defective code statement is located in the abstract syntax tree.

[0137] For example, in the first example, the line number of the second defective code statement is line 14, the code element where line 14 is located is the main() function, and the declaration position of the main() function is line 9 to line 20. In other words, the declaration position of the code element where the line number of the second defective code statement is located is line 9 to line 20, and the line number interval of the first code corresponding to line 9 to line 20 of the source code is determined according to the line number mapping relationship, and the declaration position of the code element where the first defective code statement is located can be determined.

[0138] Step 2: Determine the line number in the first code where the code element with the line number of the first defective code statement is declared by mapping the line number of each code statement in the first code to the line number of each code statement in the source code.

[0139] In this way, by performing syntax analysis on the source code to obtain the declaration position of the code element where the line number of the second defective code statement is located, and then obtaining the declaration position of the code element where the line number of the first defective code statement is located, it helps to ensure that the context content of the first defective code statement does not exceed the declaration position of the code element of the first defective code statement, thereby helping to avoid the impact of the declaration position of the code element on the defect identification.

[0140] In an embodiment of the present application, after executing step 402, the server can add a defect identifier of the defective code statement in the first code to the defective code statement in the source code if there is a mapping relationship between the line number of the defective code statement in the first code and the line number of the defective code statement in the source code. If the defective code statements in the source code have the same defect identifier, it indicates that the defective code statements in the source code are repeated, and the defective code statements in the source code in the first detection report are deduplicated.

[0141] In this way, the server can match the second defect code statement in the first detection report with the defect identifier based on the mapping relationship, thereby removing duplicate second defect code statements with repeated defect identifiers.

[0142] Specifically, after the server executes step 402, the method further includes:

[0143] A defect identifier of the first defect code statement is added to a second defect code statement that has a mapping relationship with the line number of the first defect code statement; and based on the second defect code statement with the same defect identifier, the second defect code statement in the first detection report is deduplicated.

[0144] The code defect identification method provided in the embodiment of the present application can generate a defect identifier for uniquely identifying a first defective code statement. When a second defective code statement that has a mapping relationship with the line number of the first defective code statement has the same defect identifier, it indicates that the second defective code statement in the first detection report is a duplicate second defective code statement.

[0145] Exemplarily, the defect identifier may be represented in a hash form. When there are multiple defect identifiers corresponding to the second defect code statements having the same hash value, it indicates that the multiple second defect code statements are repeated second defect code statements.

[0146] In this way, the code defect identification method provided by the embodiment of the present application can perform unified analysis and management of the first detection reports of multiple static inspection tools, identify and deduplicate the repeated second defect code statements in the first detection report, and solve the technical problem that conventional static defect inspection tools will generate a large number of false alarms.

[0147] In an embodiment of the present application, before executing step 402, the server can obtain the file name of the first code, the defect type and line number of the defective code statement in the first code based on the detection report of the existing static inspection tool, and generate a defect identifier by combining the defective code statement obtained in step 402 and the context content of the defective code statement.

[0148] In this way, the server can generate a defect identifier of the defect code statement based on the file name of the first code in the detection report and the defect type of the defect code statement in the first code, combined with the defect code statement and the context content of the defect code statement.

[0149] Specifically, before the server executes step 402, the method further includes:

[0150] The server uses a first inspection tool to perform static inspection on the first code to obtain a second inspection report; wherein the first inspection tool is any one of the existing multiple static inspection tools; the second inspection report includes the file name of the first code, the defect type of the first defective code statement and the line number of the first defective code statement; wherein the file name of the first code is the same as the file name of the source code.

[0151] In this way, by using the first inspection tool to perform a static inspection on the first code, the file name of the first code, the defect type of the first defective code statement and the line number of the first defective code statement can be obtained. There is no need to obtain the mapping relationship between the line number of each code statement in the first code and the line number of each code statement in the source code. The defect identifier can be generated by combining the defective code statement in the first code and the context content of the defective code statement in the first code, which helps to easily realize the generation of defect identifiers.

[0152] In an embodiment of the present application, the server executes step 401 and can directly obtain the file name of the first code and the defect type of the defective code statement in the first code by using a static checking tool installed on the server in the process of removing or replacing redundant information from the source code to obtain the first code. The defect identifier can be generated by combining the defective code statement obtained in step 402 and the context content of the defective code statement.

[0153] In this way, the server can directly obtain the file name of the first code used to generate the defect identifier and the defect type of the defect code statement in the first code during the process of removing or replacing redundant information from the source code to obtain the first code, which helps to easily realize the generation of defect identifiers.

[0154] Specifically, when the server executes step 401, the following steps may be included:

[0155] The server uses a second inspection tool to process the source code to obtain the first information; the first information includes the first code; wherein the second inspection tool is a preset static inspection tool, and the first information also includes the file name of the first code and the defect type corresponding to the first defect code statement; the file name of the first code is the same as the file name of the source code.

[0156] In this way, the second inspection tool provided by the embodiment of the present application can directly process the source code to obtain the first code, the file name of the first code and the defect type corresponding to the first defective code statement. There is no need to obtain the mapping relationship between the line numbers of each code statement in the first code and the line numbers of each code statement in the source code. The defect identifier can be generated in combination with the context content of the first defective code statement, which helps to easily realize the generation of defect identifiers.

[0157] In the above first possible implementation manner, it is mentioned that the process of preprocessing the source code by the server may include a first preprocessing, a second preprocessing and / or a third preprocessing. Next, the first preprocessing, the second preprocessing and the third preprocessing will be described in detail respectively.

[0158] Specifically, the server performs a first preprocessing on the source code to obtain the second code, that is, removes or replaces the syntax format elements in the source code to obtain the second code. The first preprocessing may include removing or replacing blank lines, line breaks, spaces, comments, and scopes in the code, and may also include uniformly replacing uppercase letters in the source code with lowercase letters.

[0159] In this way, the second code after the first preprocessing can avoid the change of defect identification caused by blank lines, line breaks, spaces, upper and lower case letters, comments, and changes in scope.

[0160] Figure 8 is a schematic diagram of the grammatical format elements in the source code. For example, when performing the first preprocessing, Figure 8 As shown, the server can identify the syntax format elements included in the source code, such as "space", "comment", "blank line", "line break", and "scope", and remove the syntax format elements in the source code.

[0161] Fig. 9 is a schematic diagram of the second code. After the server removes the above grammatical format elements in the source code, the second code can be obtained. Fig. 9 As shown in the figure, "spaces", "comments", "blank lines", "scopes", and "line breaks" are deleted, and the two lines of code (line 14 and line 15) are merged into one line of code.

[0162] Specifically, the second code is subjected to a second preprocessing to obtain the third code, that is, by extracting the code element containing the second defective code statement, thereby avoiding the change of the defect identification caused by changing the declaration position of the code element where the second defective code statement is located.

[0163] Fig.10 Schematic diagram of the declaration position of the code element where the second defective code statement is located. Exemplarily, after the second code is preprocessed, Fig.10 As shown, the server can identify the declaration position of the main() function where the second defective code statement is located (i.e., the part in the solid line frame). The code elements outside the declaration position of the function main() are irrelevant code elements, i.e., the code elements outside the solid line frame. In the first example, the irrelevant code elements are the code elements where the print() function is located.

[0164] The server removes irrelevant code elements, that is, removes the code elements where the print() function is located, and retains the code elements where the function main() is located, thereby avoiding the defect identification being affected by the declaration position of the function of the first defect-free code statement, and obtains the third code. Fig.11 This is a schematic diagram of the third code.

[0165] Specifically, the third code is subjected to a third preprocessing to obtain the first code, that is, by removing or replacing the character string and the identifier to avoid the change of the defect identification caused by the modification of the character string and the identifier. Fig.12 is a schematic diagram of the string and identifier in the third code. For example, Fig.12 As shown, the server can recognize the character string and identifier in the third code.

[0166] Fig.13 Schematic diagram of the first code. Exemplarily, the server performs a third preprocessing on the third code, which may be to replace both the string "whatever.txt" and the string "RESOURCE_LEAK" with the string "string", and replace the identifier "e" with the identifier "name", to obtain the following: Fig.13 The first code is shown.

[0167] In this way, since the first code is obtained after the source code undergoes the first preprocessing, the second preprocessing and the third preprocessing, the first code is obtained by removing or replacing the grammatical format elements in the source code, extracting the declaration position of the code element of the second defective code statement, and removing or replacing the character strings and identifiers. Therefore, generating defect identification based on the first code can avoid the influence of grammatical format elements, declaration positions of code elements, character strings and identifiers.

[0168] In the above second possible implementation manner, preprocessing the source code may include a third preprocessing and a first preprocessing.

[0169] Specifically, the specific implementation methods of the third preprocessing and the first preprocessing of the source code can refer to the above description, which will not be repeated here. It can be understood that when the second preprocessing is not performed on the source code, since the context content of the first defective code statement is determined, the code in the first range or the second range does not exceed the scope of the declaration position of the code element where the first defective code statement is located, therefore, the context content of the first defective code statement does not exceed the scope of the declaration position of the code element where the first defective code statement is located.

[0170] In this way, since the source code is obtained after the third preprocessing and the first preprocessing to obtain the first code, the first code is obtained after removing or replacing the grammatical format elements in the source code and removing or replacing the character strings and identifiers, and the context content of the first defect code statement used to generate the defect identifier does not exceed the declaration position of the code element of the first defect code statement. Therefore, generating the defect identifier according to the first code can avoid the influence of the grammatical format elements, the declaration position of the code elements, the character strings and identifiers.

[0171] Fig.14 Schematic diagram of the method for identifying code defects provided in the embodiment of the present application Figure 3 .like Fig.14 As shown, in the second exemplary embodiment, a method for identifying a code defect provided by an embodiment of the present application takes the processing of the source code in the first exemplary embodiment to generate a defect identification and the unified management of multiple first detection reports as an example, including:

[0172] Step 1401: The server obtains the defect type, line number and source code file name of the second defect code statement through multiple first detection reports, the first code file name is the same as the source code file name. The hash value of the initial defect identifier is 0.

[0173] Step 1402: The source code (content) is subjected to a third preprocessing by using a third formatting function (Deformat_L3 function). The server removes or replaces character strings and identifiers in the source code to obtain a second code.

[0174] Step 1403: The server performs a first preprocessing on the second code through the first formatting function (Deformat_L1 function), and removes "spaces", "comments", "blank lines" and "line breaks" in the code to obtain the first code (deformatted content).

[0175] Step 1404: during the process of preprocessing the source code, the server obtains a mapping relationship (linemap) between the line number of each code statement in the first code and the line number of each code statement in the source code.

[0176] Step 1405: The server uses the Parse() function to perform syntax analysis on the source code and outputs an error code (error) and an abstract syntax tree.

[0177] Step 1406: The server determines the first defective code statement in the first code and the defect type of the first defective code statement through the defect type, mapping relationship and line number of the second defective code statement; wherein the defect type of the first defective code statement and the defect type of the second defective code statement corresponding to the line number having a mapping relationship with the line number of the first defective code statement are the same.

[0178] Step 1407: When the syntax analysis is successful, the server outputs an error code of null, and uses the GetMethodDef() function to search the abstract syntax tree for the line number (line) of the function definition position (method define line, methodDefline) where the line number (line) of the second defective code statement is located.

[0179] Step 1408: The server obtains the line number of the definition position of the function (i.e., a type of code element) where the line number of the second defective code statement is located according to the mapping relationship, determines the line number of the first defective code statement corresponding to the line number of the second defective code statement in the first code (deformated line), and determines the line number of the definition position of the function where the line number of the second defective code statement is located corresponds to the line number of the definition position of the function where the line number of the first defective code statement is located in the first code (deformated method defline).

[0180] Step 1409: Starting from the line number of the first defective code statement, the server selects the first m lines of code statements adjacent to the first defective code statement in the first code as the context content (context) of the first defective code statement, that is, the first code is added to the first defective code statement and the context content of the first defective code statement line by line in reverse order (i.e., in order from large to small line numbers) until the number of lines of the context content exceeds the preset line number threshold n or the line number of the selected context content exceeds the line number of the definition position of the function where the first defective code statement is located.

[0181] It can be understood that when the context content of the first defective code statement is added line by line in reverse order to the first code, the context position is selected to be no greater than the function definition position of the line number of the first defective code statement. Therefore, the change in defect identification caused by changing the declaration position of the code element where the defect is located can be avoided.

[0182] Step 1410: The server performs a hash calculation based on the defect type of the first defect code statement, the file name where the first code is located, the first defect code statement, and the context content of the first defect code statement to obtain a defect identifier.

[0183] Fig.15 Schematic diagram of the method for identifying code defects provided in the embodiment of the present application Figure 4 For example, when n is 2, Fig.15 As shown, the first defective code statement and the context content of the first defective code statement involved in step 1408 are the first defective code statement and the first two lines of the first defective code statement, the file name of the source code is the main file (Main.java), and the defect type is resource leak. The server performs hash calculation based on the defect type, the file name of the source code, the first defective code statement, and the context content of the first defective code statement to generate a defect identifier.

[0184] In this way, by performing the first preprocessing and the third preprocessing on the source code, the context content of the first defective code statement is obtained without exceeding the function definition position of the first defective code statement, which can prevent the modification of the code syntax format element and the change of the position of the code element from causing the change of the defect identifier. The server generates a unique defect identifier based on the identifier calculation component related to the source code itself, which can avoid being incompatible with other static inspection tools to deduplicate the defect identifier, thereby solving the technical problem that conventional static defect inspection tools will generate a large number of false positives.

[0185] An embodiment of the present application also provides an electronic device, which includes at least a memory and one or more processors; the memory is used to store computer instructions, and when the one or more processors execute the computer instructions, the electronic device executes each function or step in the above method embodiment.

[0186] Optionally, an electronic device provided in an embodiment of the present application further includes a communication module. In some embodiments, the communication module can be used to receive source code, send the first code processed by the processor to the client, and send a defect identifier to the client.

[0187] An embodiment of the present application also provides a computer-readable storage medium, which includes computer instructions. When the computer instructions are executed on the above-mentioned electronic device, the electronic device executes each function or step in the above-mentioned method embodiment.

[0188] The embodiment of the present application also provides a computer program product. When the computer program product is run on an electronic device, the electronic device executes each function or step in the above method embodiment.

[0189] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0190] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of modules or units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0191] The units described as separate components may or may not be physically separated, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0192] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0193] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read only memory (ROM), random access memory (RAM), disk or optical disk and other media that can store program code.

[0194] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for identifying code defects, characterized in that: include: Removing or replacing redundant information in the source code to obtain a first code; wherein the redundant information includes grammatical format elements, identifiers and character strings in the source code, and the first code includes one or more first defective code statements and one or more first non-defective code statements; Generate a defect identifier for the first defective code statement according to the file name of the source code, the defect type corresponding to the first defective code statement, the first defective code statement, and the context content of the first defective code statement; wherein the defect identifier is used to uniquely identify the first defective code statement; The context content of the first defective code statement includes: the first m lines of code statements adjacent to the first defective code statement in the first code, and / or the last n lines of code statements adjacent to the first defective code statement in the first code, where m and n are not zero at the same time; The removing or replacing redundant information in the source code to obtain the first code includes: Processing the source code with a second checking tool to obtain first information; the first information includes the first code; Among them, the second inspection tool is a preset static inspection tool, and the first information also includes the file name of the first code and the defect type corresponding to the first defective code statement; the file name of the first code is the same as the file name of the source code.

2. The method according to claim 1, characterized in that: Before generating a defect identifier for the first defective code statement according to the file name of the source code, the defect type corresponding to the first defective code statement, the first defective code statement, and the context content of the first defective code statement, the method further includes: Obtain multiple first detection reports of the source code; wherein the multiple first detection reports are obtained by using multiple static inspection tools to perform static inspection on the source code respectively; the first detection report includes the file name of the source code, the defect type of the second defective code statement in the source code, and the line number of the second defective code statement; In the process of removing or replacing the redundant information in the source code to obtain the first code, obtaining a mapping relationship between a line number of each code statement in the first code and a line number of each code statement in the source code; The defect types of the first defective code statement and the first defective code statement in the first code are determined by the mapping relationship and the line number of the second defective code statement; wherein the defect type of the first defective code statement is the same as the defect type of the second defective code statement corresponding to the line number having a mapping relationship with the line number of the first defective code statement.

3. The method according to claim 2, characterized in that Before generating a defect identifier for the first defective code statement according to the file name of the source code, the defect type corresponding to the first defective code statement, the first defective code statement, and the context content of the first defective code statement, the method further includes: Obtaining the line number of the first defective code statement; the line number of the first defective code statement is the line number of the first defective code statement in the first code; The first m lines of code statements include m lines of code statements adjacent to the line number of the first defective code statement, and the last n lines of code statements include n lines of code statements adjacent to the line number of the first defective code statement.

4. The method according to claim 3, characterized in that The obtaining the line number of the first defective code statement includes: Obtaining the line number of the second defective code statement; the line number of the second defective code statement is the line number of the second defective code statement in the source code; The line number of the first defective code statement corresponding to the line number of the second defective code statement is obtained through the mapping relationship between the line number of each code statement in the first code and the line number of each code statement in the source code.

5. The method according to any one of claims 1, 2 or 4, characterized in that: The first m lines of code statements are adjacent to the first defective code statement, are before the first defective code statement, and are included in the declaration position of the code element where the first defective code statement is located; The following n lines of code statements are adjacent to the first defective code statement, are after the first defective code statement, and are included in the declaration position of the code element where the first defective code statement is located.

6. The method according to claim 5, characterized in that The source code includes one or more second defective code statements; Before generating a defect identifier for the first defective code statement according to the file name of the source code, the defect type corresponding to the first defective code statement, the first defective code statement, and the context content of the first defective code statement, the method further includes: Performing syntax analysis on the source code to obtain a syntax analysis result; wherein the syntax analysis result indicates a declaration position of a code element where a line number of the second defective code statement is located; The line number of the declaration position of the code element where the line number of the first defective code statement is located in the first code is determined through the mapping relationship between the line number of each code statement in the first code and the line number of each code statement in the source code.

7. The method according to claim 2, characterized in that: After generating a defect identifier for the first defective code statement according to the file name of the source code, the defect type corresponding to the first defective code statement, the first defective code statement, and the context content of the first defective code statement, the method further includes: Adding a defect identifier of the first defective code statement to a second defective code statement having the mapping relationship with the line number of the first defective code statement; Based on the second defect code statement with the same defect identifier, the second defect code statement in the first detection report is deduplicated.

8. The method according to claim 1, characterized in that: Before generating a defect identifier for the first defective code statement according to the file name of the source code, the defect type corresponding to the first defective code statement, the first defective code statement, and the context content of the first defective code statement, the method further includes: A first inspection tool is used to perform static inspection on the first code to obtain a second inspection report; wherein, the first inspection tool is any one of multiple existing static inspection tools; the second inspection report includes the file name of the first code, the defect type of the first defective code statement and the line number of the first defective code statement; wherein, the file name of the first code is the same as the file name of the source code.

9. The method according to claim 1, characterized in that: The grammatical format elements include at least: spaces in each code statement in the source code, blank lines between code statements, line breaks in each code statement, comments on code statements, and scopes of code statements.

10. An electronic device, characterized in that: The electronic device comprises at least a memory and one or more processors; the memory is used to store computer instructions, and when the one or more processors execute the computer instructions, the electronic device executes the method as claimed in any one of claims 1 to 9.

11. A computer-readable storage medium, characterized in that: The method comprises computer instructions, which, when executed on an electronic device, cause the electronic device to execute the method as claimed in any one of claims 1 to 9.

12. A computer program product, characterized in that When the computer program product is executed on an electronic device, the electronic device is caused to execute the method according to any one of claims 1 to 9.

Images