Risk code detection method, computer readable storage medium and equipment

Abstract

The invention provides a risk code detection method, a computer readable storage medium and equipment, and the method comprises the steps: obtaining a to-be-detected code which is composed of at least one code element; identifying a target code element belonging to a target type from the to-be-detected code; and under the condition that the target code element is marked with the waste annotation, determining that the to-be-detected code has the risk of using the waste code.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a risk code detection method, a computer-readable storage medium, and a device. Background Art

[0002] During software development, to ensure compatibility with older versions and a smooth system transition, developers often mark the code to be eliminated as deprecated code by annotating it with deprecated annotations. This type of code does not generate abnormal error messages during compilation and is allowed to be called in the short term to maintain business continuity. However, from a long-term perspective, as the software is updated, deprecated code will gradually threaten the stability and security of the software, and will also significantly increase maintenance costs. Therefore, how to detect deprecated code in a timely manner has become a problem that the industry continues to solve.

[0003] In related technologies, deprecated code is usually identified proactively through the promotion of coding standards and the personal experience of developers, or manual code review is used to detect whether there is a risk of using deprecated code in the code. However, the above methods all rely on manual investigation and are easily affected by subjective factors, which leads to a large time and manpower cost in the detection process, and the accuracy of the detection results is difficult to guarantee. Summary of the Invention

[0004] In view of this, this specification provides a risk code detection method and device to address the deficiencies in the related art.

[0005] Specifically, this specification is implemented through the following technical solutions:

[0006] According to a first aspect of an embodiment of this specification, a method for detecting a risk code is provided, the method comprising:

[0007] Obtaining a code to be detected, where the code to be detected is composed of at least one code element;

[0008] Identifying target code elements belonging to a target type from the code to be detected;

[0009] In a case where the target code element is marked with a deprecated annotation, it is determined that the code to be detected has a risk of using deprecated code.

[0010] According to a second aspect of the embodiments of this specification, a computer-readable storage medium is provided, on which a computer program is stored. When the program is executed by a processor, the steps of the method described in the first aspect are implemented.

[0011] According to a third aspect of the embodiments of this specification, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the steps of the method described in the first aspect are implemented.

[0012] The technical solution provided in this specification can identify target code elements of a target type from a code to be tested, which is composed of at least one code element, and confirm the marking of deprecated annotations. If the target code element is marked with a deprecated annotation, it can be determined that the code to be tested has the risk of using deprecated code. This helps developers efficiently discover and confirm risks that cannot be discovered during the compilation process, and avoids the occurrence of reduced software stability and security and increased maintenance costs. Since the entire risk detection process does not rely on human participation, it does not consume a lot of time and labor costs, and accuracy can also be guaranteed.

[0013] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0015] Figure 1 This is a flow chart of a risk code detection method shown in an exemplary embodiment of this specification;

[0016] Figure 2 is a flow chart of another risk code detection method shown in an exemplary embodiment of this specification;

[0017] Figure 3 This is a flow chart of a method for detecting risk codes in incremental codes, shown in an exemplary embodiment of this specification;

[0018] Figure 4 is a structural diagram of an electronic device shown in an exemplary embodiment of this specification;

[0019] Figure 5 It is a structural diagram of a risk code detection device shown in an exemplary embodiment of this specification. DETAILED DESCRIPTION

[0020] Exemplary embodiments are described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all possible embodiments consistent with this specification. Rather, they are merely examples of apparatuses and methods consistent with certain aspects of this specification.

[0021] It should be noted that in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than those described in this specification. In addition, a single step described in this specification may be broken down into multiple steps for description in other embodiments, and multiple steps described in this specification may be combined into a single step for description in other embodiments. It should be understood that although this specification may use terms such as first, second, and third to describe various information, such information should not be limited to these terms. These terms are merely used to distinguish between information of the same type. For example, first information may also be referred to as second information, and similarly, second information may be referred to as first information, without departing from the scope of this specification. Depending on the context, the term "if" as used herein can be interpreted as "when," "when," or "in response to a determination."

[0022] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this manual are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and corresponding operation entrances are provided for users to choose to authorize or refuse.

[0023] The following describes in detail an embodiment of the risk code detection method of this specification with reference to the accompanying drawings.

[0024] Figure 1 This is a flow chart of a risk code detection method shown in an exemplary embodiment of this specification. Figure 1 As shown, the method may include the following steps:

[0025] Step S101: Acquire a code to be detected, where the code to be detected is composed of at least one code element.

[0026] When software developers need to detect the risk of abandoned code, they need to provide a code to be detected as the detection object. The code to be detected can be a complete software project, a module, a file, or a specific code fragment. The above-mentioned code elements are the basic units that constitute the code to be detected, which can include classes, methods, interfaces, fields, packages, arrays, enumerations, etc. Of course, the code elements in different programming languages ​​are different in name and usage. Based on this, this manual uses Java as the default programming language corresponding to each code element below to ensure the consistency of the code elements.

[0027] The above-mentioned code to be detected may be included in a corresponding program to be detected. At the same time, the program to be detected may include one or more files to be detected storing different codes to be detected and other files that do not include the code to be detected (such as device configuration files, media information files, etc.). In addition, the above-mentioned program to be detected may come from a locally written engineering project, or a code library based on a version control system in a server, such as a distributed version control system GIT or a centralized version control system (Subversion, SVN), and this specification does not limit this.

[0028] The technical solution of this specification can filter out other files in the above-mentioned program to be detected, and carry out risk code detection operations on the above-mentioned files to be detected.

[0029] In one embodiment, after obtaining the source file of the program to be detected, the file to be detected that matches the preset file format can be filtered out from the source file, and the preset file format can be used to indicate that the corresponding file has detectable code; the files to be detected are traversed in sequence, and the code in the traversed files to be detected is used as the code to be detected. Specifically, the preset file format can be based on the programming language used by the program to be detected, for example: in the program to be detected based on the Java language, "java" is the file format of the file to be detected of the program to be detected, and in the program to be detected based on the C++ (c plus plus) language, "cpp" is the file format of the file to be detected of the program to be detected; further, the filtered files to be detected can be recorded in a preset file list to facilitate the subsequent sequential traversal of the code to be detected contained in each file to be detected. The filtered files to be detected can exclude invalid files such as configuration files with the format name "config" or Extensible Markup Language (XML) files with the format name "xml" that do not have the risk of discarded code, thereby effectively improving the detection efficiency of the code to be detected that has the risk of using discarded code.

[0030] The method of obtaining the code to be tested based on the source file of the program to be tested in the above embodiment is a special case in this specification, which requires the software developer to fully understand the source file of the program to be tested. However, in actual application scenarios, for various reasons such as protecting code logic, maintaining commercial interests, reducing unnecessary information, simplifying usage processes, and cross-team collaboration, the code to be tested provided by the software developer is often not the source code of the source file, but the object code (Object code) generated by compiling or assembling the source file, or a comprehensive file containing both the source code and the object code.

[0031] The target code is a type of machine language code that a computer can directly understand and execute. Different programming languages ​​generate different target codes. For example, in Java programming, source files in the "java" format are compiled by the Java compiler to generate bytecode files in the "class" format. These "class" files are the target code of the Java program. In C or C++ programming, source files in the "c" or "cpp" format are processed by the compiler to generate executable files or target files, such as exe files in Windows or o files in Linux. These executable files and target files also fall under the category of target code. Because target code and source files differ significantly in format and readability, this presents an obstacle for software developers to directly obtain code elements from the code to be tested.

[0032] Based on this, this specification provides a unified processing method for the code to be detected below, so as to ensure that the corresponding code elements are successfully obtained from the code to be detected.

[0033] Step S104: identifying target code elements belonging to a target type from the code to be detected.

[0034] After obtaining the code to be detected, it is necessary to filter out specific types of target code elements from it. These specific types are the target types. Taking the Java language as an example, the above target types can be at least one type of class, method, interface, enumeration, field, constructor and annotation, which can be customized by the developer. The common point is that they can all be marked with obsolete annotations in the corresponding language. The above-mentioned obsolete annotation is a special annotation used to mark that a code element is outdated and is not recommended for use. In short, by identifying the code elements of the target type, the detection scope of the code to be detected can be narrowed down, and the detection targeting and efficiency can be improved.

[0035] As mentioned above, the above-mentioned code to be detected may include source code and / or target code. Based on this, in this specification, the above-mentioned code to be detected can be regarded as target code for processing, so as to identify the above-mentioned target code elements.

[0036] In one embodiment, the above-mentioned code to be detected can be uniformly compiled into corresponding target codes, and at the same time, target code elements matching the target type can be identified from the target code based on the manipulation framework for the above-mentioned target code and the operation instructions corresponding to the above-mentioned target type. Among them, the above-mentioned compilation operation can be determined specifically according to the type of the code to be detected. If the code to be detected belongs to the source code, it can be normally compiled into the corresponding target code; if the code to be detected already belongs to the compiled target code, the above-mentioned compilation operation can be ignored. In other words, this embodiment achieves unified processing of different types of codes by uniformly compiling the code to be detected into target codes and using the manipulation framework and operation instructions to identify target code elements, thereby improving the versatility and efficiency of code analysis. In addition, the above-mentioned manipulation framework can adapt to target codes generated by different programming languages, and can read target code information and analyze it, such as the Java Bytecode Manipulation Framework (ASM) for Java language, the dynamic binary instrumentation tool set (Dyninst) for C and C++ languages, the low-level virtual machine (LLVM), etc. In short, whether it is Java bytecode, C or C++ machine code, or compiled products of other languages, they can be effectively analyzed and processed through the corresponding framework, providing software developers with a universal and efficient code analysis solution. In addition, in this application, by manipulating the framework, the first type of target code compiled in the above-mentioned code to be detected and the second type of target code originally carried can be conveniently analyzed, avoiding many difficulties such as decompiling the target code into source code. Specifically, the decompilation process is not only difficult and inefficient, but may not be able to completely restore the original logic and structure of the code, resulting in inaccurate analysis results, making it impossible to identify target code elements belonging to the target type from the code to be detected.

[0037] The specific execution method for the above-mentioned operation instructions can be determined by combining the manipulation framework and the target type. Taking ASM (Java bytecode manipulation framework) as an example, if a developer needs to determine whether the code elements of classes and interface methods in the code to be tested are marked with deprecated annotations, the following steps can be followed: First, identify target code elements from the target code that match these two target types. Specifically, ASM's ClassReader class can be used to load target files in the class format. These target files can either already exist or be generated by compiling the code to be tested. Next, the getClassName method is called to obtain the class names of all classes in the target file. During the ClassReader call, the getInterfaces method is called to obtain a list of all interface-based methods (i.e., the aforementioned interface methods) in the current class. Based on the results of these two method calls, the manipulation framework can determine whether the code to be tested contains target code elements of the corresponding target type. Alternatively, taking Dyninst as an example, if a developer needs to determine whether the code elements of member functions (which can be used as Java methods) in the C++ program to be tested are marked with deprecated annotations, the target code elements that match these two target types can be identified from the target code. Specifically, you can use the BPatch class in Dyninst as the operation entry, that is, first create a BPatch object, then use its openBinary method to load the binary executable file as the target code, obtain the image information of the binary file through the getImage method of the BPatch_binaryEdit object, and then use the findFunction series of methods of the image information to find member functions in the program.

[0038] In short, this specification does not restrict the selection of the manipulation framework and the corresponding target type. Developers can determine the specific identification method for the target code element based on the actual situation of the two.

[0039] Step S106 : When the target code element is marked with a deprecated annotation, it is determined that the code to be detected has a risk of using deprecated code.

[0040] After the target code elements are identified, it is possible to check whether these elements are marked with deprecated annotations. If the target code elements are marked with deprecated annotations, it means that these deprecated codes are used in the code to be tested, and there are certain risks, such as compatibility issues or functional abnormalities in future versions. On the contrary, it means that the code to be tested has advantages in terms of compatibility and functional implementation. Specifically, the method for determining whether the target code elements are marked with deprecated annotations can refer to the above-mentioned target code element identification process. Still taking the Java language as an example, various annotations including the deprecated annotation "@Deprecated" can rely on other code elements such as classes, methods, and fields to provide additional information for them. Therefore, the annotation attributes of the corresponding code elements can be obtained through the Java language's getAnotation method, and the Java language's contains method can be used in the obtained annotation attributes to determine whether the above-mentioned deprecated annotations are contained. If the judgment result indicates that it exists, it means that the corresponding code element is marked with a deprecated annotation, otherwise it is not marked.

[0041] It is worth mentioning that the above-mentioned deprecated annotations themselves are usually written by the "programming language core development team" or "software developers who use the programming language for project development". For the former, deprecated annotations can be added to old functions of the standard library, code elements with security or performance issues, and old features that do not conform to the direction of language development, so as to ensure language compatibility, guide developers to use new features, and improve security and performance; for the latter, during the project development and maintenance process, according to changes in business needs, code refactoring, and compliance with expected practices, deprecated annotations can be added to code elements that are no longer applicable in the project but cannot be deleted immediately.

[0042] In addition, when it is determined that the target code element is marked with a deprecated annotation, the target code element can be recorded to facilitate the management and tracking of the deprecated code and to promptly discover the risk of incremental code using deprecated code.

[0043] In one embodiment, when the target code element is marked with an obsolete annotation, the risk element information of the target code element can be recorded in a historical obsolete code list, and when the detected code is added with incremental code after the detection is completed, the target incremental code element whose element information is consistent with the risk element information recorded in the historical obsolete code list is queried from the incremental code. If the query result is not empty, it is determined that the incremental code has the risk of using obsolete code; correspondingly, if the query result is empty, it is determined that the incremental code does not have the risk of using obsolete code. Among them, the historical obsolete code list serves as a repository for storing risk element information of code elements that have been determined to be obsolete in the code to be detected. It can adopt an array, list or other suitable data structure according to actual needs, and this specification does not limit this. Incremental code refers to new code that is added to meet new requirements, optimize functions or refactor the purpose on the basis of the detected code, reflecting the changes and iterations of the code base over time. In this specification, it is assumed that the incremental code is written in accordance with the correct code specifications and does not include new obsolete code other than the above-mentioned code to be detected.

[0044] Below is Figure 2 Taking as an example, a method for obtaining target code elements marked with deprecated annotations from the code to be detected and adding them to the above-mentioned historical deprecated code list is introduced. The method includes the following steps:

[0045] Step S202: Obtain the project source code from the project source code management repository as the code to be tested.

[0046] In one embodiment, suppose that during the development of a software project, a developer needs to perform a code obsolescence check. First, they can obtain the project's source code. For example, using the git clone command can conveniently copy the entire project from a source code management repository such as GitHub or GitLab to their local environment. By entering the corresponding gitclone command and specifying the repository address in the command line, the project source code is downloaded to a designated directory as the code to be checked, providing a foundation for subsequent compilation and checking operations.

[0047] Step S204: compile the project source code into a jar package or a war package.

[0048] In one embodiment, after successfully acquiring the code to be tested, assuming the software project is a Java project built based on Maven, the command mvn clean package can be used to compile and package it. mvn clean cleans the files generated by the project compilation to ensure a clean compilation environment; mvn package compiles the project and generates a jar or war package based on the project configuration. These packaged files contain the project's executable code, facilitating subsequent processing.

[0049] Step S206: decompress the jar package or war package and find all target files.

[0050] In one embodiment, the compiled jar package or war package needs to be decompressed in order to further analyze the target code therein, that is, the class file. The unzip command can be used to release the files in the package to a specified location. The decompressed folder contains various files and directories of the project. In order to ensure the implementation of abandoned code detection, all class files can be found. The class file is a bytecode file compiled by Java and contains the actual execution logic of the code. Specifically, a script or program can be written, starting from the decompressed root directory, recursively traversing all subdirectories, filtering out files with the file extension class, and collecting them as target files for subsequent analysis.

[0051] Step S208: Load the target files in sequence and obtain the class names of all classes in each target file.

[0052] In one embodiment, assuming the developer only needs to check whether the interface-based methods in each class in the code being tested are marked with deprecated annotations, the identified target files can be loaded using ASM's ClassReader method. This ClassReader reads the target file's bytecode content and parses it into internal data structures for subsequent extraction and analysis of class information. By calling the ClassReader method on each target file in sequence, these files can be loaded and processed one by one. Simultaneously, the ASM getClassName method can be called to obtain the name of the class defined in the corresponding target file.

[0053] Step S210, determine whether loading is abnormal.

[0054] In one embodiment, when using ClassReader to load a class file, exception detection can be performed to avoid loading anomalies caused by file corruption, format errors, etc. If the loading is normal, step S212 is executed to call the getInterfaces method to obtain information about all interfaces implemented by the current class. An interface defines the method specifications that the corresponding class must implement. Otherwise, an exception report is generated and step S208 is attempted again.

[0055] Step S212: Obtain the annotation attributes of the interface method.

[0056] In one embodiment, after obtaining the interface method list, the getAnnotation method can be used to obtain the annotation attributes of each method respectively.

[0057] Step S214: determine whether the discarded annotation is included.

[0058] In one embodiment, after obtaining the annotation attributes of a method, the `contains` method can be used to check whether it contains the deprecated annotation `@Deprecated`. If the detection result indicates that this annotation is included, the method has been marked as deprecated, and step S216 can be executed to record its risk element information. If the detection result indicates that this annotation is not included, the method has not been marked as deprecated, and step S212 can be re-executed until every method in the interface method list is fully checked.

[0059] Step S216: Add the risk element information to the historical abandoned code list.

[0060] In one embodiment, the recorded information can be added to the historical abandoned code list in the form of, for example, {the class name of the class where the method is located, the method name, the method type, and the method parameters}, to facilitate the subsequent management and processing of the abandoned code, such as risk assessment when adding incremental code.

[0061] The above-mentioned risk element information may include the element name and element type of the target code element, so as to accurately identify the characteristics of the target code element so that it can be compared and matched with other code elements in subsequent code analysis. In particular, this manual can use "class" as a demarcation to make targeted records according to the following three situations of the target code element. For example, when checking whether independent code elements outside the class are called in the incremental code, only the first type of risk element information needs to be paid attention to; when checking whether the abandoned class is used, the second type of risk element information needs to be checked; when checking whether the abandoned members in the class are called, the third type of risk element information needs to be checked. This can reduce unnecessary matching operations and improve detection efficiency.

[0062] In one embodiment, for the first case: when the target code element includes an independent code element defined outside a class, the element name, element type, and element parameters of the independent code element can be recorded as the first type of risk element information in the historical abandoned code list. Specifically, the independent code element can be a method, interface, or enumeration defined outside a class. For example, there is an independent method named "fun1" whose element type is a method and receives two floating-point type parameters for calculating a sum. When the method is marked with an abandoned annotation, the element name "fun1", the element type of the corresponding method, and the element parameters "floating-point number num1, floating-point number num2" can be recorded as the first type of risk element information in the historical abandoned code list. Alternatively, there is an independent interface such as "imp1" whose element type is an interface and has no parameters. If it is marked with an abandoned annotation, its element name "imp1", the element type of the corresponding interface, and the parameter information with empty content can be recorded as the first type of risk element information. Alternatively, consider an independent enumeration "enum1" with an enumeration element type and no parameters. When it is marked as deprecated, the element name "enum1," the element type enumeration, and the empty parameter information can be recorded as first-category risk element information. Regarding the second scenario, if the target code element includes a target class, the class name and type of the target class are recorded as second-category risk element information in the historical deprecated code list. It should be understood that any class, whether ordinary, abstract, or inner, falls under the category of target class. For example, consider a common class named "class1," of class type, used to manage user information. When this class is marked deprecated due to business adjustments or architectural upgrades, the class name "class1" and the corresponding class element type are recorded as second-category risk element information in the historical deprecated code list. Similarly, although the inner class is defined within another class, it is essentially a class. If the inner class "class3" within "class2" is marked deprecated, the class name "class2.class3" and the corresponding class element type are recorded. For the third case: when the above-mentioned target code element includes the target member defined in the above-mentioned class, the class name of the class where the above-mentioned target member is located, the member name, member type and member parameters of the above-mentioned target member are recorded as the third type of risk element information in the above-mentioned historical abandoned code list. Specifically, the members in the class can include methods, fields, constructors, enumerations, and annotations. Taking methods as an example, there is a method "fun2" in the "class4" class, the member type is method, and it receives an integer type parameter "id" for obtaining old product information. When the method is marked as abandoned, the class name "class4", member name "fun2", member type method and member parameters of the class, that is, the integer "Id" will be recorded as the third type of risk element information.For fields, suppose the class "class5" contains a field "fields1" with a field member type and no parameters. If it is marked as discarded, the class name "class5," the member name "fields1," the member type field, and the parameterless information will be recorded. In this embodiment, risk element information is recorded based on the different situations of the target code elements, accurately identifying the corresponding features, reducing subsequent matching operations and improving detection efficiency.

[0063] Those skilled in the art will understand that the actual correspondence between the types of target code elements and the above three situations is related to the programming language. For example, in Java, there are generally no fields, constructors, and annotations outside the class, because they are usually closely related to the class, and interfaces usually do not exist as members of the class; for example, in Python, fields, functions (which can be regarded as Java's constructor functions) and decorators (which can be regarded as Java's annotations) outside the class do not need to rely on classes and exist independently, and Python does not have a strict concept of interface like Java, so there is no question of whether the interface is a member of the class.

[0064] In addition to the aforementioned element names, element types, and element parameters, additional information such as version information and package names can be added to risk element information based on actual circumstances. With regard to version information, this can prevent situations where, for example, after a code update, the name or parameters of a code element change, resulting in the risk element information in the historical deprecated code list not being accurately matched to the code element in the incremental code. With regard to package names, this can prevent situations where, for example, in a large project, classes or methods with the same name are defined in multiple modules, making it impossible to accurately distinguish the target code element from other code based solely on the name and parameters.

[0065] In the process of querying the above-mentioned target incremental code element, the characteristics of the above-mentioned first-category risk element information, second-category risk element information and third-category risk element information can be combined for implementation.

[0066] In one embodiment, the above-mentioned first-category risk element information, the above-mentioned second-category risk element information, and the above-mentioned third-category risk element information in the above-mentioned historical discarded code list can be sequentially compared with the element information in the above-mentioned incremental code according to the element comparison rules; when the comparison result indicates that at least one risk element information is consistent with the element information in the above-mentioned incremental code, the element information can be determined as the above-mentioned target incremental code element. Among them, this embodiment requires that different types of risk element information be compared one by one through the above-mentioned element comparison rules to systematically traverse the incremental code, thereby ensuring that the query operation of the target incremental code element of the incremental code covers code elements at different levels to avoid missing risks. At the same time, it also simplifies the detection process, which helps developers understand and debug the detection logic, so as to facilitate debugging and accurately locate problems. For example, when there is a problem with the detection result, the above-mentioned developer can step by step and orderly check which type of risk element information has an abnormality according to the steps of sequential comparison required by the element comparison rules. And according to the characteristics of each risk element information, a suitable comparison method is adopted to more accurately find the situation that is consistent with the element information in the incremental code. For example, for the first type of risk element information, attention should be paid to the element name, type and parameters when comparing; for the third type of risk element information, in addition to the member's own information, the information of the class to which it belongs should also be considered. Of course, in addition to comparing various types of risk element information with the element information in the incremental code in a predetermined order, the above-mentioned element comparison rules can also configure specified types of risk element information to participate in the above comparison according to the actual needs of developers, or compare various types of risk element information and the element information in the incremental code based on other orders. This manual does not limit this.

[0067] In the process of querying the above-mentioned target incremental code elements, this specification can also improve the query efficiency for the target incremental code elements based on the Abstract Syntax Tree (AST) and adapt to different code structures.

[0068] In one embodiment, the incremental code can be first parsed to obtain the corresponding abstract syntax tree, and then the alternative element information of the code element matching the target type in the incremental code can be queried based on the abstract syntax tree. When at least one alternative element information queried is consistent with the risk element information, the code element corresponding to the at least one alternative element information can be determined as the target incremental code element. If each alternative element information is inconsistent with the risk element information, it can be determined that the incremental code does not contain the target incremental code element, and thus does not contain the risk element information, as well as the risk of using abandoned code. Among them, the alternative element information can be implemented based on the Extensible Markup Language Path Language (XML Path Language, XPath). Since XPath can efficiently search the abstract syntax tree, which is a file in XML format, it provides a technical basis for this specification to query the nodes and attributes in the abstract syntax tree below.

[0069] In the process of querying the above-mentioned alternative element information, assuming that the incremental code is based on annotations referencing obsolete code in the above-mentioned detected code, then the annotation nodes in the abstract syntax tree can be queried, the above-mentioned annotation nodes can be traversed in sequence, and the element nodes corresponding to the traversed annotation nodes can be obtained. In the case where the above-mentioned element nodes correspond to the above-mentioned target type, the above-mentioned alternative element information can be determined based on the node attributes of the above-mentioned element nodes. In other words, for the case where the incremental code references obsolete code based on annotations, the obsolete code reference can be accurately located by querying the annotation nodes and element nodes of the abstract syntax tree, thereby adapting to the corresponding reference method. For example, the incremental code mentioned above does not contain the deprecated annotation "@Deprecated", but the developer uses automatic injection annotations such as "@Autowired" to unintentionally reference deprecated code in the detected code that has been marked with the deprecated annotation. Assuming that the deprecated code in the detected code only corresponds to classes, when the target type is determined to be a class, the XPath expression " / ClassOrInterfaceBodyDeclaration / Annotation / MarkerAnnotation / Name[@image="Autowired"]" can be used to identify each annotation node in the abstract syntax tree of the code marked with the automatic injection annotation in the incremental code. At the same time, for each annotation node, the XPath expression "classorintefacestype[@image]" is used to query the classorintefacestype node under the same ClassOrInterfaceBodyDeclaration node as the corresponding Annotation node, that is, the aforementioned element node. The class name of the class corresponding to each classorintefacestype node is extracted through the node attributes as candidate element information to facilitate consistency comparison of the second type of risk element information mentioned above. The specific abstract syntax tree can be referred to as follows:

[0070] <root>

[0071] <classorinterfacebodydeclaration>

[0072] <annotation>

[0073] <makeanotaion>

[0074] <name iamge="Autowired">

[0075] < / makeanotaion>

[0076] < / annotation>

[0077] <classorintefacestype image="com.example.service.MyService">< / classorintefacest ype>

[0078] < / classorinterfacebodydeclaration>

[0079] < / root>

[0080] Of course, developers can set it up according to actual needs to directly compare at least one alternative element information queried with the risk element information during each traversal of the above-mentioned annotation nodes to increase the efficiency of detecting abandoned code in incremental code; or it can be set up to uniformly compare at least one alternative element information queried with the risk element information after the traversal of the above-mentioned annotation nodes is completed to ensure the coverage of abandoned code detection in incremental code.

[0081] Assuming that the obsolete code in the detected code includes not only classes but also methods called in classes, the target type can be determined as classes and methods, and the statement block for method calls in the incremental code can be extracted through the XPath expression " / primaryprefix / name / [@image]". Specifically, the primaryprefix usually represents the main part of a method call or expression, corresponding to the obj part of obj.method in Java. The child node name of the primaryprefix node can be a method name, corresponding to the method of obj.method in Java. The image attribute can be used to store the name of an identifier, such as a method name in character format. Obtain the method referenced by each class in the statement block, and determine whether the called method is in the historical obsolete code list. If none of them are in the historical obsolete code list, it means that there is no obsolete code call in the incremental code. Otherwise, it means that there is at least one call to obsolete code in the incremental code.

[0082] The above embodiments are based on prior knowledge of the type and reference method of the deprecated code in the incremental code. This allows for the configuration of the corresponding XPath expression, allowing for rapid identification of candidate element information and comparison with risky element information in the abstract syntax tree. Even without knowing the type and reference method, this specification also allows for a depth-first traversal of the abstract syntax tree generated by the incremental code to record the node attributes of each element node and compare them with the historical deprecated code list using a combination of fuzzy and exact matching.

[0083] Furthermore, semantic analysis can be performed based on the abstract syntax tree, combining programming language grammar rules and code logic to determine whether method calls, class instantiations, and other procedures involve deprecated code. Machine learning and natural language processing techniques can also be used to train classification models to assist in detection. Of course, if possible references to deprecated code are discovered, they are marked. Uncertain references are then facilitated through annotations, logging, and other methods for manual review, thereby reducing the risk of using deprecated code and ensuring code quality and maintainability.

[0084] It is worth mentioning that as incremental code is detected and processed, new deprecated code may be discovered or existing deprecated code information may be updated. Therefore, the historical deprecated code list can be updated according to actual conditions to ensure its accuracy and completeness, providing a reliable basis for subsequent code detection.

[0085] The following combination Figure 3 , the risk code detection process of incremental code is introduced, which includes the following steps:

[0086] Step S302: Obtain a list of incremental code files and obtain Java source files.

[0087] In one embodiment, the git diff command can be used to accurately obtain a list of code files involved in the newly added code based on the detected code, thereby clearly defining the scope of the code changes. Furthermore, source files with the suffix "java" can be searched from the obtained file list, and the paths of these source files can be added to the incremental list of files to be analyzed. This is consistent with the abandoned code detection method for Java code in this embodiment. In other words, focusing on Java source files can improve the targetedness of detection.

[0088] Step S304: traverse the incremental files to be analyzed and construct a corresponding abstract syntax tree.

[0089] In one embodiment, each source file in the incremental list of files to be analyzed can be processed in turn. By traversing, it is ensured that all newly added Java files are fully tested. Specifically, for each Java file in the list, a corresponding Java abstract syntax tree can be constructed.

[0090] Step S306: Detect the abandoned code referenced by the class.

[0091] In one embodiment, the XPath expression / ClassOrInterfaceBodyDeclaration / Annotation / MarkerAnnotation / Name[@image="Autowired"] is used to match code related to class references in a file. Furthermore, the XPath expression ClassOrInterfaceType[@image] can be used to extract the class name of the referenced class in the code. The extracted class name is then compared with a list of historically deprecated code.

[0092] Step S308: Determine whether the reference detection result of the class is normal.

[0093] In one embodiment, if after traversing all class reference-related codes, the referenced class name is not in the historical abandoned code list, step S310 is executed to continue analyzing whether the code file uses abandoned methods; if there is a reference to an abandoned class, step S316 is executed.

[0094] Step S310: Detect abandoned code of method calls.

[0095] In one embodiment, the XPath expression / primaryprefix / name / [@image] can be used to extract the statement blocks of method calls in the code file. The called method names are obtained from these statement blocks and compared with the historical abandoned code list.

[0096] Step S312: determine whether the method call detection result is normal.

[0097] In one embodiment, if none of the called methods are in the historical abandoned code list, it means that there is no abandoned code call in the code file, the file is marked as passed, and step S314 is executed; if there is a called method in the historical abandoned code list, it means that there is an abandoned code call in the code file, and step S316 is executed.

[0098] Step S314: Determine that the code file does not contain any abandoned code calls.

[0099] Step S316: Determine whether the code file contains abandoned code calls.

[0100] In one embodiment, if a class name is found to exist in the historical abandoned code list, it indicates that the code uses abandoned code. The risk information can be recorded and a heterogeneous subsequent detection report can be generated. The risk information may include file path, referenced abandoned class name, method name, etc.

[0101] Step S318: Generate a test report.

[0102] In one embodiment, whether step S314 or step S316 is executed, a detailed detection report can be generated based on the recorded risk information after completing the detection of all files in the incremental file list to be analyzed. The report content may include a list of files with abandoned code calls, specific abandoned class and abandoned method information, risk level assessment, etc. Based on the detection report, developers can take corresponding measures. For files with abandoned code calls, developers can make modifications in a timely manner to replace abandoned classes or methods, or organize special discussions and develop comprehensive solutions to ensure the quality and maintainability of the code. At the same time, the detection results are fed back to the code submitter to remind him or her to avoid using abandoned code in subsequent development.

[0103] Figure 4 This is a schematic structural diagram of an electronic device in an exemplary embodiment. Figure 4 At the hardware level, the electronic device includes a processor, an internal bus, a network interface, memory, and non-volatile storage, and may also include other necessary hardware. The processor reads the corresponding computer program from the non-volatile storage into the memory and then runs it, forming a risk code detection device at the logical level. Of course, in addition to software implementation, this specification does not exclude other implementation methods, such as logic devices or a combination of software and hardware. In other words, the execution subject of the following processing flow is not limited to individual logic units, but can also be hardware or logic devices.

[0104] Corresponding to the aforementioned embodiment of the risk code detection method, this specification also provides an embodiment of the risk code detection device.

[0105] Please refer to Figure 5 , Figure 5 FIG. 1 is a schematic diagram of a risk code detection device according to an exemplary embodiment. Figure 5 As shown, the device may include:

[0106] A code acquisition unit 502 is configured to acquire a code to be detected, wherein the code to be detected is composed of at least one code element;

[0107] A code element identification unit 504 is configured to identify a target code element of a target type from the code to be detected;

[0108] The risk determination unit 506 is configured to determine, when the target code element is marked with a deprecated annotation, whether the code to be detected has a risk of using deprecated code.

[0109] Optionally, the code element identification unit 504 is specifically configured to:

[0110] Compiling the code to be detected into corresponding target code;

[0111] A target code element matching the target type is identified from the target code based on a manipulation framework for the target code and an operation instruction corresponding to the target type.

[0112] Optionally, the device further includes:

[0113] an incremental code risk determination unit, which records risk element information of the target code element into a historical discarded code list when the target code element is marked with a discarded annotation;

[0114] In the case where incremental code is added to the detected code after detection is completed, searching the incremental code for a target incremental code element whose element information is consistent with the risk element information recorded in the historical discarded code list;

[0115] When the query result is not empty, it is determined that the incremental code has a risk of using obsolete code.

[0116] Optionally, the incremental code risk determination unit is specifically configured to perform at least one of the following:

[0117] In a case where the target code element includes an independent code element defined outside a class, recording the element name, element type, and element parameters of the independent code element as first-category risk element information in the historical discarded code list;

[0118] In the case where the target code element includes a target class, recording the class name and type of the target class as second-category risk element information in the historical discarded code list;

[0119] In the case where the target code element includes a target member defined in a class, the class name of the class to which the target member belongs, the member name, member type and member parameters of the target member are recorded as third-category risk element information in the historical discarded code list.

[0120] Optionally, the incremental code risk determination unit is specifically configured to:

[0121] Compare the first-category risk element information, the second-category risk element information, and the third-category risk element information in the historical discarded code list with the element information in the incremental code in sequence according to an element comparison rule;

[0122] When the comparison result indicates that at least one item of risk element information is consistent with the element information in the incremental code, the element information is determined as the target incremental code element.

[0123] Optionally, the incremental code risk determination unit is specifically configured to:

[0124] Parsing the incremental code to obtain a corresponding abstract syntax tree;

[0125] Querying the incremental code for candidate element information of code elements matching the target type according to the abstract syntax tree;

[0126] In a case where the at least one candidate element information found is consistent with the risk element information, the code element corresponding to the at least one candidate element information is determined as the target incremental code element.

[0127] Optionally, the incremental code references the discarded code in the detected code based on the annotation; the incremental code risk determination unit is specifically configured to:

[0128] The querying, according to the abstract syntax tree, the candidate element information of the code element matching the target type in the incremental code includes:

[0129] Querying the annotation nodes in the abstract syntax tree;

[0130] Traverse the annotation nodes in sequence and obtain the element nodes corresponding to the traversed annotation nodes;

[0131] In a case where the element node corresponds to the target type, the candidate element information is determined according to a node attribute of the element node.

[0132] Optionally, the code to be detected is included in a program to be detected, and the device further includes:

[0133] A source file detection unit, configured to obtain the source file of the program to be detected;

[0134] Filtering out a file to be detected that matches a preset file format from the source file, wherein the preset file format is used to indicate that the corresponding file has a detectable code;

[0135] The files to be detected are traversed in sequence, and the codes in the traversed files to be detected are used as the codes to be detected.

[0136] The implementation process of the functions and effects of each unit in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0137] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the partial description of the method embodiments. The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this specification. A person of ordinary skill in the art can understand and implement it without paying any creative work.

[0138] Embodiments of the subject matter and functional operations described in this specification may be implemented in the following: digital electronic circuits, tangibly embodied computer software or firmware, computer hardware including the structures disclosed in this specification and their structural equivalents, or a combination of one or more of them. Embodiments of the subject matter described in this specification may be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible, non-transitory program carrier to be executed by a data processing device or to control the operation of the data processing device. Alternatively or additionally, the program instructions may be encoded on an artificially generated propagation signal, such as a machine-generated electrical, optical, or electromagnetic signal, which is generated to encode information and transmit it to a suitable receiver device for execution by the data processing device. The computer storage medium may be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them.

[0139] The processes and logic flows described in this specification can be performed by one or more programmable computers executing one or more computer programs to perform the corresponding functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can be implemented as, special purpose logic circuitry, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

[0140] Computers suitable for executing computer programs include, for example, general-purpose and / or special-purpose microprocessors, or any other type of central processing unit. Typically, the central processing unit will receive instructions and data from a read-only memory and / or random access memory. The basic components of a computer include a central processing unit for implementing or executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, such as magnetic disks, magneto-optical disks, or optical disks, or the computer will be operably coupled to such mass storage devices to receive data from them or to transmit data to them, or both. However, a computer does not necessarily have such devices. In addition, a computer can be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device such as a universal serial bus (USB) flash drive, to name a few.

[0141] Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and storage devices, including, for example, semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD ROM and DVD-ROM disks. The processor and memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0142] Although this specification includes many specific implementation details, these should not be interpreted as limiting the scope of any invention or the scope of protection claimed, but are mainly used to describe the features of specific embodiments of specific inventions. Certain features described in multiple embodiments within this specification may also be implemented in combination in a single embodiment. On the other hand, the various features described in a single embodiment may also be implemented separately in multiple embodiments or in any suitable sub-combination. In addition, although features may work in certain combinations as described above and even initially claimed as such, one or more features from the claimed combination may be removed from the combination in some cases, and the claimed combination may point to a sub-combination or a variation of the sub-combination.

[0143] Similarly, although operations are depicted in a particular order in the accompanying drawings, this should not be understood as requiring that these operations be performed in the particular order shown or performed sequentially, or that all illustrated operations be performed to achieve the desired results. In some cases, multitasking and parallel processing may be advantageous. In addition, the separation of various system modules and components in the above-described embodiments should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product, or packaged into multiple software products.

[0144] Thus, specific embodiments of the subject matter have been described. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the particular order shown or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing may be advantageous.

[0145] The above description is only a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this specification should be included in the scope of protection of this specification.

Claims

1. A method for detecting risk codes, characterized in that: The method comprises: Obtaining a code to be detected, where the code to be detected is composed of at least one code element; Identifying target code elements belonging to a target type from the code to be detected; In a case where the target code element is marked with a deprecated annotation, it is determined that the code to be detected has a risk of using deprecated code.

2. The method according to claim 1, characterized in that The step of identifying a target code element belonging to a target type from the code to be detected includes: Compiling the code to be detected into corresponding target code; A target code element matching the target type is identified from the target code based on a manipulation framework for the target code and an operation instruction corresponding to the target type.

3. The method according to claim 1, characterized in that The method further comprises: In the case where the target code element is marked with a discarded annotation, recording the risk element information of the target code element into a historical discarded code list; In the case where incremental code is added to the detected code after detection is completed, searching the incremental code for a target incremental code element whose element information is consistent with the risk element information recorded in the historical discarded code list; When the query result is not empty, it is determined that the incremental code has a risk of using obsolete code.

4. The method according to claim 3, characterized in that The step of recording the risk element information of the target code element into a historical discarded code list includes at least one of the following: In a case where the target code element includes an independent code element defined outside a class, recording the element name, element type, and element parameters of the independent code element as first-category risk element information in the historical discarded code list; In the case where the target code element includes a target class, recording the class name and type of the target class as second-category risk element information in the historical discarded code list; In the case where the target code element includes a target member defined in a class, the class name of the class to which the target member belongs, the member name, member type and member parameters of the target member are recorded as third-category risk element information in the historical discarded code list.

5. The method according to claim 4, characterized in that The step of searching the incremental code for a target incremental code element whose element information is consistent with the risk element information recorded in the historical discarded code list includes: Compare the first-category risk element information, the second-category risk element information, and the third-category risk element information in the historical discarded code list with the element information in the incremental code in sequence according to an element comparison rule; When the comparison result indicates that at least one item of risk element information is consistent with the element information in the incremental code, the element information is determined as the target incremental code element.

6. The method according to claim 4, characterized in that The step of searching the incremental code for a target incremental code element whose element information is consistent with the risk element information recorded in the historical discarded code list includes: Parsing the incremental code to obtain a corresponding abstract syntax tree; Querying the incremental code for candidate element information of code elements matching the target type according to the abstract syntax tree; In a case where the at least one candidate element information found is consistent with the risk element information, the code element corresponding to the at least one candidate element information is determined as the target incremental code element.

7. The method according to claim 6, characterized in that The incremental code references the obsolete code in the detected code based on the annotation; The querying, according to the abstract syntax tree, the candidate element information of the code element matching the target type in the incremental code includes: Querying the annotation nodes in the abstract syntax tree; Traverse the annotation nodes in sequence and obtain the element nodes corresponding to the traversed annotation nodes; In a case where the element node corresponds to the target type, the candidate element information is determined according to a node attribute of the element node.

8. The method according to claim 1, characterized in that The code to be detected is included in the program to be detected, and the method further includes: Obtaining the source file of the program to be detected; Filtering out a file to be detected that matches a preset file format from the source file, wherein the preset file format is used to indicate that the corresponding file has a detectable code; The files to be detected are traversed in sequence, and the codes in the traversed files to be detected are used as the codes to be detected.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the steps of the method according to any one of claims 1 to 8 are implemented.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the steps of the method according to any one of claims 1 to 8 are implemented.

Images