A method and device for standardizing code verification

Abstract

The present application discloses a method and device for code standard verification, which is applied to the field of data processing technology, including: obtaining the code tree and target exclusion list corresponding to the development project; detecting whether the module corresponding to the token is in the target exclusion list for each token; if not, determining whether the token is a package definition token; if so, performing package definition processing on the token; if not, extracting the import module from the token, and detecting whether the import module is in the target exclusion list; if not, checking whether the dependency relationship corresponding to the import module meets the specification requirements; if not, recording error information and feeding back the error information to the front end. Thus, by extending the function of the Checkstyle plug-in, it can adapt to the code structure of different projects, and then perform in-depth verification on the code structure of different projects to ensure that all developed codes meet the specification requirements of the project.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a method and device for standardizing and verifying a code. Background Art

[0002] With the development of science and technology, the software development industry has grown rapidly, and the software application field has become increasingly complex, which has led to a sharp increase in the amount of code supporting software operation. Therefore, it is necessary to automatically verify whether the code is standardized during code development, so as to improve code development efficiency and code maintainability.

[0003] Among the existing code verification methods, the Checkstyle code verification tool is mainly used. The Checkstyle code verification tool helps developers follow unified code writing specifications by defining a series of code rules. However, the Checkstyle code verification tool may not be able to fully cover the verification requirements of the code structure corresponding to a specific project. Therefore, it is necessary to manually verify the code structure corresponding to the specific project, which leads to low verification efficiency of such code, affecting the development efficiency of developers. Summary of the invention

[0004] Based on the above-mentioned deficiencies of the prior art, the present application provides a method and device for standardizing code verification to solve the problem that the prior art cannot cover the code verification requirements corresponding to all projects.

[0005] In order to achieve the above objectives, this application provides the following technical solutions:

[0006] The first aspect of the present application provides a method for standard verification of a code, comprising:

[0007] Obtain a code tree and a target exclusion list corresponding to the development project; wherein the target exclusion list refers to an exclusion list after initialization; and each node in the code tree represents a token;

[0008] For each of the tokens, detecting whether the module corresponding to the token is in the target exclusion list;

[0009] If the module corresponding to the token does not exist in the target exclusion list, determining whether the token is a package definition token;

[0010] If the token is the package definition token, performing package definition processing on the token;

[0011] If the token is a non-package definition token, extracting an import module from the token, and detecting whether the import module is in the target exclusion list;

[0012] If it is detected that the imported module does not exist in the target exclusion list, check whether the dependency relationship corresponding to the imported module meets the specification requirements;

[0013] If the dependency relationship corresponding to the imported module does not meet the specification requirements, error information is recorded and fed back to the front end; wherein the error information at least includes the dependency relationship that does not meet the specification requirements.

[0014] Optionally, in the above-mentioned method for checking the code specification, the step of obtaining the code tree and the target exclusion list corresponding to the development project includes:

[0015] Acquiring development projects;

[0016] Reading a rule set from the development project; wherein the rule set at least includes a code structure and an exclusion list;

[0017] Initialize the exclusion list to obtain a target exclusion list corresponding to the development project, and perform tree conversion on the code structure to obtain a code tree corresponding to the development project.

[0018] Optionally, in the above-mentioned method for checking the code specification, the performing package definition processing on the token includes:

[0019] Obtaining the target code corresponding to the token;

[0020] The package name corresponding to the token is extracted from the target code.

[0021] Optionally, in the above-mentioned code specification verification method, the step of checking whether the dependency relationship corresponding to the imported module meets the specification requirements includes:

[0022] According to the dependency relationship corresponding to the imported module, detecting whether the imported module depends on other imported modules;

[0023] If the import module depends on other import modules, then check whether the import module complies with the dependency rules;

[0024] If the imported module does not comply with the dependency rule, determining that the dependency relationship corresponding to the imported module does not comply with the specification requirements;

[0025] If the import module does not depend on other import modules, or the import module complies with the dependency rule, the specification verification of the development project is ended.

[0026] Optionally, in the above-mentioned code standard verification method, it also includes:

[0027] If the module corresponding to the token exists in the target exclusion list, or the imported module exists in the target exclusion list, or the dependency relationship corresponding to the imported module meets the specification requirements, the specification verification of the development project is terminated.

[0028] The second aspect of the present application provides a code standard verification device, including:

[0029] A data acquisition unit, used to acquire a code tree and a target exclusion list corresponding to a development project; wherein the target exclusion list refers to an exclusion list after initialization; and each node in the code tree represents a token;

[0030] A first detection unit, configured to detect, for each of the tokens, whether a module corresponding to the token is in the target exclusion list;

[0031] a token determination unit, configured to determine whether the token is a package definition token if a module corresponding to the token does not exist in the target exclusion list;

[0032] a processing unit, configured to perform package definition processing on the token if the token is the package definition token;

[0033] a second detection unit, configured to extract an import module from the token if the token is a non-package definition token, and detect whether the import module is in the target exclusion list;

[0034] A checking unit, configured to check whether the dependency relationship corresponding to the imported module meets specification requirements if it is detected that the imported module does not exist in the target exclusion list;

[0035] A recording unit is used to record error information if the dependency relationship corresponding to the imported module does not meet the specification requirements, and feed back the error information to the front end; wherein the error information at least includes the dependency relationship that does not meet the specification requirements.

[0036] Optionally, in the above-mentioned code standard verification device, the data acquisition unit includes:

[0037] Project Acquisition Unit, used to acquire development projects;

[0038] A reading unit, used for reading a rule set from the development project; wherein the rule set at least includes a code structure and an exclusion list;

[0039] The initialization unit is used to initialize the exclusion list, obtain a target exclusion list corresponding to the development project, and perform tree conversion on the code structure to obtain a code tree corresponding to the development project.

[0040] Optionally, in the above-mentioned code standard checking device, the processing unit includes:

[0041] A code acquisition unit, used to acquire a target code corresponding to the token;

[0042] An extraction unit is used to extract the package name corresponding to the token from the target code.

[0043] Optionally, in the above-mentioned code standard checking device, the checking unit includes:

[0044] A third detection unit, configured to detect whether the imported module depends on other imported modules according to the dependency relationship corresponding to the imported module;

[0045] a fourth detection unit, configured to detect whether the import module complies with a dependency rule if the import module depends on other import modules;

[0046] A determination unit, configured to determine that the dependency relationship corresponding to the imported module does not meet the specification requirements if the imported module does not meet the dependency rule;

[0047] The first ending unit is used to end the specification verification of the development project if the import module does not depend on other import modules or the import module meets the dependency rule.

[0048] Optionally, in the above-mentioned code standard verification device, it also includes:

[0049] The second ending unit is used to end the specification verification of the development project if the module corresponding to the token exists in the target exclusion list, or the imported module exists in the target exclusion list, or the dependency relationship corresponding to the imported module meets the specification requirements.

[0050] The present application provides a method for standard verification of a code, by obtaining a code tree and a target exclusion list corresponding to a development project, wherein the target exclusion list refers to an exclusion list after initialization, and each node in the code tree represents a token, and for each token, the module corresponding to the token is detected to be in the target exclusion list, and if the module corresponding to the token does not exist in the target exclusion list, it is determined whether the token is a package definition token, and if the token is a package definition token, the token is package defined, and if the token is a non-package definition token, the import module is extracted from the token, and the import module is detected to be in the target exclusion list, and if the import module is detected to be in the target exclusion list, the dependency corresponding to the import module is checked to be in compliance with the specification requirements, and if the dependency corresponding to the import module does not meet the specification requirements, the error information is recorded, and the error information is fed back to the front end, wherein the error information at least includes the dependency that does not meet the specification requirements. Thus, by extending the function of the Checkstyle plug-in, it is possible to adapt to the code structure of different projects, and then perform in-depth verification on the code structure of different projects to ensure that all developed codes meet the specification requirements of the project. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0052] Figure 1 A flowchart of a method for standardizing code verification provided by an embodiment of the present application;

[0053] Figure 2 A flowchart of a method for acquiring data provided in an embodiment of the present application;

[0054] Figure 3 A schematic diagram of the structure of the dependency relationship between modules provided in an embodiment of the present application;

[0055] Figure 4 A schematic diagram of the structure of the dependency relationship within a module provided in an embodiment of the present application;

[0056] Figure 5 A flowchart of a package definition processing method provided by another embodiment of the present application;

[0057] Figure 6 A flowchart of a standard verification method for an import module provided in another embodiment of the present application;

[0058] Figure 7A flowchart of another method for checking the standard of a code provided in another embodiment of the present application;

[0059] Figure 8 A flowchart of a code verification integration method provided in another embodiment of the present application;

[0060] Fig. 9 A schematic diagram of the structure of a code standard verification device provided in another embodiment of the present application. DETAILED DESCRIPTION

[0061] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0062] In this application, relational terms such as first and second, etc. are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "comprise", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the statement "comprises a ..." does not exclude the presence of other identical elements in the process, method, article or device including the element.

[0063] The present application embodiment provides a method for standard verification of a code, such as Figure 1 As shown, the specific steps include:

[0064] S101. Obtain a code tree and a target exclusion list corresponding to a development project.

[0065] The target exclusion list refers to the initialized exclusion list. Each node in the code tree represents a token.

[0066] It should be noted that the embodiment of the present application first extends the Checkstyle plug-in so that the extended Checkstyle plug-in can meet the code verification requirements of all projects. The extended Checkstyle plug-in integrates the inspection of inter-module dependencies, calling order within modules, module structure and repository interface usage. Therefore, through the configuration file, the Checkstyle plug-in can adapt to the structural specifications of different projects, and the Checkstyle plug-in can run on the client or the server to achieve seamless integration into the developer's workflow.

[0067] Specifically, the Checkstyle plug-in will be loaded first to obtain the development project to be checked, and then the Checkstyle plug-in will automatically parse the development project to generate a code tree and obtain a target exclusion list.

[0068] Optionally, in another embodiment of the present application, a specific implementation of step S101 is as follows: Figure 2 As shown, the following steps are included:

[0069] S201. Obtain development projects.

[0070] Alternatively, if you are getting the development project in an integrated development environment (IDE) such as IntelliJ IDEA or Visual Studio Code (VS Code), you can directly open the project folder or clone the project from the Git repository. Because most modern IDEs have built-in Git integration, you can get the project code directly from the IDE.

[0071] For example, IntelliJ IDEA: Select File→New→Project from Version Control→Enter the Git repository address.

[0072] VS Code: Select View→Source Control→Select Clone Repository.

[0073] S202. Read a rule set from a development project.

[0074] It should be noted that the rule set can be read from the development project first, and then read into the memory for storage, wherein the rule set is a Checkstyle custom rule, and the rule set can include code structure, exclusion list, dependencies, and some configurable items.

[0075] The dependencies can be found in Figure 3The dependencies between modules are shown, and Figure 4 Dependencies within the modules are shown. Figure 3 and Figure 4 Presentation user interface layer, application layer, domain layer, and infrastructure basic layer.

[0076] Specifically, modules are only allowed to communicate through the application layer. Within the module, infrastructure->presentation->application->domain, these are all one-way dependencies. The naming of each layer may be inconsistent in each project. Some projects may call the user interface layer module A and module B, so you need to customize and load them.

[0077] It should also be noted that the exclusion list is designed to take into account that not all modules in the development project need to follow the Checkstyle custom rules. For example, module a needs to follow the Checkstyle custom rules, but module b does not need to follow the rules, so module b needs to be excluded.

[0078] S203, initializing an exclusion list, obtaining a target exclusion list corresponding to the development project, and performing tree conversion on the code structure to obtain a code tree corresponding to the development project.

[0079] Specifically, if you want to initialize the exclusion list, you will extract the Checkstyle custom rules from the configuration file of the development project in step S202, then build an exclusion list based on the Checkstyle custom rules, and finally recursively traverse the directory structure of the development project to build a tree representation to exclude unnecessary files and directories.

[0080] For example, steps S201 to S203 may be implemented by the following code:

[0081] import os

[0082] import fnmatch

[0083] # Initialize the exclusion list

[0084] excluded_files = [

[0085] "*.class",

[0086] "*.log",

[0087] ".DS_Store",

[0088] ".idea / "

[0089] "target / "

[0090] "build / "

[0091] "** / test / **"

[0093] # Traverse and build the code tree

[0094] def build_code_tree(root_dir):

[0095] code_tree = {}

[0096] for root, dirs, files in os.walk(root_dir):

[0097] # Remove directories in the exclusion list

[0098] dirs[:] = [d for d in dirs if not any(fnmatch.fnmatch(d, excl) for excl in excluded_files)]

[0099] files[:] = [f for f in files if not any(fnmatch.fnmatch(f, excl) for excl in excluded_files)]

[0100] relative_path = os.path.relpath(root, root_dir)

[0101] node = code_tree

[0102] if relative_path != ".":

[0103] parts = relative_path.split(os.sep)

[0104] for part in parts:

[0105] node = node.setdefault(part, {})

[0106] for file in files:

[0107] ​node[file] = None

[0108] return code_tree

[0109] #Execute code tree construction

[0110] code_tree = build_code_tree('my_project')

[0111] print(code_tree).

[0112] S102. For each token, check whether the module corresponding to the token is in the target exclusion list.

[0113] It should be noted that in order to accurately identify and exclude modules or files that do not need to be processed in the development project, ensure the standardization of the code structure, and the efficiency and accuracy of other processing operations, each token can be detected separately to see whether the module corresponding to the token is in the target exclusion list. Because each token can be regarded as a module or file, if the module corresponding to the token does not exist in the target exclusion list, it means that the module corresponding to the token does not need to be excluded from the project, so step S103 is executed.

[0114] Optionally, if the data volume of the token and target exclusion lists is very large, the matching efficiency may be improved by preprocessing the exclusion rules into regular expressions or using a set data structure.

[0115] S103: Determine whether the token is a package definition token.

[0116] It should be noted that, considering that different token types correspond to different specification verification rules, it is necessary to determine the type of token in advance, where the token types are divided into package definition tokens and import tokens. Package definition tokens generally refer to identifiers or keywords used to declare or reference packages, that is, the package name of the module. Import tokens refer to keywords, symbols or identifiers used to import other modules, packages or libraries in programming languages.

[0117] Therefore, when the module corresponding to the token does not exist in the target exclusion list, it is necessary to first determine whether the token is a package definition token. If the token is a package definition token, step S104 is executed. If the token is a non-package definition token, that is, the token is an import token, step S105 is executed.

[0118] S104: Perform package definition processing on the token.

[0119] Specifically, when the token is a package definition token, the full name of the package in the token needs to be extracted to know which module the token belongs to. In other words, when the token is a package definition token, extracting the full name of the package is equivalent to the modularization specification of the code.

[0120] Optionally, in another embodiment of the present application, a specific implementation of step S104 is as follows: Figure 5 As shown, the following steps are included:

[0121] S501. Obtain the target code corresponding to the token.

[0122] Specifically, according to the code tree, the target code corresponding to the token is extracted from the code structure of the development project.

[0123] S502: Extract the package name corresponding to the token from the target code.

[0124] It can be understood that once the structure of the target code is obtained, the target code can be traversed to extract the package name corresponding to the token.

[0125] For example, package

[0126] abc.presentation;

[0127] import

[0128] abc.application;

[0129] import

[0130] bcd.infrastructure;

[0131] public class HelloWorld{

[0132] public static void main(String[] args){

[0133] System.out.println("Hello World!");

[0134] }

[0135] }.

[0136] The package name in package abc.presentation is abc.presentation, and you only need to extract the module presentation.

[0137] S105: Extract the import module from the token, and detect whether the import module is in the target exclusion list.

[0138] It should be noted that when the token is a non-package defined token, it means that the token is an import token, that is, other modules need to be imported into the token. In this case, it is necessary to extract the corresponding import module from the token, that is, the module carrying the import field. Then, it is necessary to determine whether the import module exists in the target exclusion list, so as to know whether to exclude the import module. Therefore, if it is detected that the import module does not exist in the target exclusion list, execute step S106.

[0139] S106. Check whether the dependency relationship corresponding to the imported module meets the specification requirements.

[0140] It should be emphasized that when it is detected that the imported module does not exist in the target exclusion list, it means that the imported module does not need to be excluded. In order to effectively avoid potential errors, improve code quality, reduce security risks, improve system performance, and ensure the smooth progress of software development, it is also necessary to check whether the dependencies corresponding to the imported modules meet the specification requirements. If the dependencies corresponding to the imported modules meet the specification requirements, execute step S107.

[0141] Among them, the dependencies corresponding to the imported modules can be obtained in the development project, and after obtaining the dependencies corresponding to the imported modules, the dependencies need to be initialized, which can ensure the normal operation of the software system, avoid runtime errors, reduce resource waste, and improve the stability, maintainability and security of the system. Through the standardized initialization process, the dependencies of the project can be managed and optimized, the development process can be simplified, and the system can be ensured to be efficient, reliable and easy to expand.

[0142] Optionally, in another embodiment of the present application, a specific implementation of step S106 is as follows: Figure 6 As shown, the following steps are included:

[0143] S601. Detect whether an imported module depends on other imported modules according to the dependency relationship corresponding to the imported module.

[0144] It should be noted that, for an import module, its imported module can be determined by directly analyzing its code. For example, the import statement in the requests source code can be viewed to understand the modules it depends on. Therefore, the import statement can be used to detect whether the import module depends on other import modules. If the import module depends on other import modules, step S602 is executed. If the import module does not depend on other import modules, step S604 is executed.

[0145] S602: Check whether the imported module complies with the dependency rules.

[0146] It is understandable that when an import module depends on other import modules, it is necessary to detect whether the import module complies with the dependency rules, so as to know whether the import module complies with the specification check. Therefore, if the import module does not comply with the dependency rules, it means that the import module does not comply with the specification requirements, so step S603 is executed. If the import module complies with the dependency rules, it means that the import module complies with the specification requirements, so step S604 is executed.

[0147] S603: Determine that the dependency relationship corresponding to the imported module does not meet specification requirements.

[0148] Specifically, when the imported module does not comply with the dependency rules, it can be determined that the code structure of the development project does not meet the standard verification. At this time, error information can be fed back to the front end to help developers quickly identify and solve the problem.

[0149] S604. End the specification verification of the development project.

[0150] It is understandable that when an import module does not depend on other import modules, or the import module complies with the dependency rules, the next token can be checked to see if it complies with the specification verification, thereby knowing whether the development project as a whole complies with the specification verification.

[0151] S107. Record error information and feed back the error information to the front end.

[0152] The error information at least includes dependencies that do not meet specification requirements.

[0153] Specifically, when the dependency relationship corresponding to the imported module does not meet the specification requirements, it is necessary to record the error information in a timely manner and feedback the error information to the developer so that the developer can quickly locate the error and correct it to avoid affecting the research and development of the development project.

[0154] The present application provides a method for standard verification of a code, by obtaining a code tree and a target exclusion list corresponding to a development project, wherein the target exclusion list refers to an exclusion list after initialization, and each node in the code tree represents a token, and for each token, the module corresponding to the token is detected to be in the target exclusion list, and if the module corresponding to the token does not exist in the target exclusion list, it is determined whether the token is a package definition token, and if the token is a package definition token, the token is package defined, and if the token is a non-package definition token, the import module is extracted from the token, and the import module is detected to be in the target exclusion list, and if the import module is detected to be in the target exclusion list, the dependency corresponding to the import module is checked to be in compliance with the specification requirements, and if the dependency corresponding to the import module does not meet the specification requirements, the error information is recorded, and the error information is fed back to the front end, wherein the error information at least includes the dependency that does not meet the specification requirements. Thus, by extending the function of the Checkstyle plug-in, it is possible to adapt to the code structure of different projects, and then perform in-depth verification on the code structure of different projects to ensure that all developed codes meet the specification requirements of the project.

[0155] Another embodiment of the present application provides another method for checking the code standard, such as Figure 7 As shown, the specific steps include:

[0156] S701. Obtain a code tree and a target exclusion list corresponding to a development project.

[0157] The target exclusion list refers to the initialized exclusion list. Each node in the code tree represents a token.

[0158] It should be noted that the specific implementation of step S701 may refer to step S101 in the above method embodiment, and will not be described in detail here.

[0159] S702: For each token, check whether the module corresponding to the token is in the target exclusion list.

[0160] It should be noted that the specific implementation of step S702 may refer to step S102 in the above method embodiment, which will not be described in detail here.

[0161] It should also be noted that if the module corresponding to the token does not exist in the target exclusion list, step S703 is executed. If the module corresponding to the token exists in the target exclusion list, step S708 is executed.

[0162] S703: Determine whether the token is a package definition token.

[0163] It should be noted that the specific implementation of step S703 may refer to step S104 in the above method embodiment, which will not be described in detail here.

[0164] It should also be noted that if the token is a package-defined token, step S704 is executed. If the token is a non-package-defined token, step S705 is executed.

[0165] S704: Perform package definition processing on the token.

[0166] It should be noted that the specific implementation of step S704 may refer to step S104 in the above method embodiment, which will not be described in detail here.

[0167] S705: Extract the import module from the token, and detect whether the import module is in the target exclusion list.

[0168] It should be noted that the specific implementation of step S705 may refer to step S105 in the above method embodiment, and will not be described in detail here.

[0169] It should also be noted that if the detection import module does not exist in the target exclusion list, step S706 is executed. If the detection import module exists in the target exclusion list, step S708 is executed.

[0170] S706: Check whether the dependency relationship corresponding to the imported module meets the specification requirements.

[0171] It should be noted that the specific implementation of step S706 may refer to step S106 in the above method embodiment, which will not be described in detail here.

[0172] It should also be noted that if the dependency relationship corresponding to the imported module does not meet the specification requirements, step S707 is executed. If the dependency relationship corresponding to the imported module meets the specification requirements, step S708 is executed.

[0173] S707. Record error information and feed back the error information to the front end.

[0174] The error information at least includes dependencies that do not meet specification requirements.

[0175] It should be noted that the specific implementation of step S707 may refer to step S107 in the above method embodiment, which will not be described in detail here.

[0176] S708. End the specification verification of the development project.

[0177] Specifically, when the module corresponding to the token exists in the target exclusion list, or the imported module exists in the target exclusion list, or the dependency relationship corresponding to the imported module meets the specification requirements, it can be said that the token and the imported module meet the specification verification, and then the specification verification of the next token can be continued until all tokens are completed.

[0178] It should be noted that the embodiments of the present application can be integrated and run on the client or server, so please refer to Figure 8 The code verification integration method shown.

[0179] Another embodiment of the present application provides a code standard verification device, such as Fig. 9 As shown, it includes the following units:

[0180] The data acquisition unit 901 is used to acquire the code tree and target exclusion list corresponding to the development project. The target exclusion list refers to the initialized exclusion list. Each node in the code tree represents a token.

[0181] The first detection unit 902 is used to detect, for each token, whether the module corresponding to the token is in the target exclusion list.

[0182] The token determination unit 903 is configured to determine whether the token is a package definition token if the module corresponding to the token does not exist in the target exclusion list.

[0183] The processing unit 904 is configured to perform package definition processing on the token if the token is a package definition token.

[0184] The second detection unit 905 is configured to extract an import module from the token if the token is a non-package definition token, and detect whether the import module is in the target exclusion list.

[0185] The checking unit 906 is used to check whether the dependency relationship corresponding to the imported module meets the specification requirements if the detected imported module does not exist in the target exclusion list.

[0186] The recording unit 907 is used to record error information if the dependency relationship corresponding to the imported module does not meet the specification requirements, and feed back the error information to the front end, wherein the error information at least includes the dependency relationship that does not meet the specification requirements.

[0187] It should be noted that the specific working process of the above modules in the embodiment of the present application can refer to steps S101 to S107 in the above method embodiment, which will not be repeated here.

[0188] Optionally, in a code standard verification device provided by another embodiment of the present application, the data acquisition unit 901 includes:

[0189] Project acquisition unit, used to acquire development projects.

[0190] The reading unit is used to read the rule set from the development project, wherein the rule set at least includes a code structure and an exclusion list.

[0191] The initialization unit is used to initialize the exclusion list, obtain the target exclusion list corresponding to the development project, and perform tree conversion on the code structure to obtain the code tree corresponding to the development project.

[0192] Optionally, in a code standard verification device provided by another embodiment of the present application, the processing unit 904 includes:

[0193] The code acquisition unit is used to acquire the target code corresponding to the token.

[0194] The extraction unit is used to extract the package name corresponding to the token from the target code.

[0195] Optionally, in a code standard checking device provided in another embodiment of the present application, the checking unit 906 includes:

[0196] The third detection unit is used to detect whether the imported module depends on other imported modules according to the dependency relationship corresponding to the imported module.

[0197] The fourth detection unit is used to detect whether the imported module complies with the dependency rule if the imported module depends on other imported modules.

[0198] The determination unit is used to determine that the dependency relationship corresponding to the imported module does not meet the specification requirements if the imported module does not meet the dependency rule.

[0199] The first ending unit is used to end the specification verification of the development project if the imported module does not depend on other imported modules or the imported module meets the dependency rule.

[0200] Optionally, a code standard verification device provided in another embodiment of the present application further includes:

[0201] The second ending unit is used to end the specification verification of the development project if the module corresponding to the token exists in the target exclusion list, or the imported module exists in the target exclusion list, or the dependency relationship corresponding to the imported module meets the specification requirements.

[0202] It should be noted that the specific working process of each module provided in the above embodiments of the present application can refer to the corresponding steps in the above method embodiments, which will not be repeated here.

[0203] It should also be noted that the code standard verification device provided in the embodiment of the present application has the technical effects of any of the above embodiments, and the embodiment of the present application will not be described in detail here.

[0204] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0205] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for standard verification of a code, characterized in that: include: Obtain a code tree and a target exclusion list corresponding to the development project; wherein the target exclusion list refers to an exclusion list after initialization; and each node in the code tree represents a token; For each of the tokens, detecting whether the module corresponding to the token is in the target exclusion list; If the module corresponding to the token does not exist in the target exclusion list, determining whether the token is a package definition token; If the token is the package definition token, performing package definition processing on the token; If the token is a non-package definition token, extracting an import module from the token, and detecting whether the import module is in the target exclusion list; If it is detected that the imported module does not exist in the target exclusion list, check whether the dependency relationship corresponding to the imported module meets the specification requirements; If the dependency relationship corresponding to the imported module does not meet the specification requirements, error information is recorded and fed back to the front end; wherein the error information at least includes the dependency relationship that does not meet the specification requirements.

2. The method according to claim 1, characterized in that The obtaining of the code tree and target exclusion list corresponding to the development project includes: Acquiring development projects; Reading a rule set from the development project; wherein the rule set at least includes a code structure and an exclusion list; Initialize the exclusion list to obtain a target exclusion list corresponding to the development project, and perform tree conversion on the code structure to obtain a code tree corresponding to the development project.

3. The method according to claim 1, characterized in that The performing package definition processing on the token includes: Obtaining the target code corresponding to the token; The package name corresponding to the token is extracted from the target code.

4. The method according to claim 1, characterized in that: The checking whether the dependency relationship corresponding to the imported module meets the specification requirements includes: According to the dependency relationship corresponding to the imported module, detecting whether the imported module depends on other imported modules; If the import module depends on other import modules, then check whether the import module complies with the dependency rules; If the imported module does not comply with the dependency rule, determining that the dependency relationship corresponding to the imported module does not comply with the specification requirements; If the import module does not depend on other import modules, or the import module complies with the dependency rule, the specification verification of the development project is ended.

5. The method according to claim 1, characterized in that Also includes: If the module corresponding to the token exists in the target exclusion list, or the imported module exists in the target exclusion list, or the dependency relationship corresponding to the imported module meets the specification requirements, the specification verification of the development project is terminated.

6. A device for checking the standard of a code, characterized in that: include: A data acquisition unit, used to acquire a code tree and a target exclusion list corresponding to a development project; wherein the target exclusion list refers to an exclusion list after initialization; and each node in the code tree represents a token; A first detection unit, configured to detect, for each of the tokens, whether a module corresponding to the token is in the target exclusion list; a token determination unit, configured to determine whether the token is a package definition token if a module corresponding to the token does not exist in the target exclusion list; a processing unit, configured to perform package definition processing on the token if the token is the package definition token; a second detection unit, configured to extract an import module from the token if the token is a non-package definition token, and detect whether the import module is in the target exclusion list; A checking unit, configured to check whether the dependency relationship corresponding to the imported module meets specification requirements if it is detected that the imported module does not exist in the target exclusion list; A recording unit is used to record error information if the dependency relationship corresponding to the imported module does not meet the specification requirements, and feed back the error information to the front end; wherein the error information at least includes the dependency relationship that does not meet the specification requirements.

7. The device according to claim 6, characterized in that The data acquisition unit comprises: Project Acquisition Unit, used to acquire development projects; A reading unit, used for reading a rule set from the development project; wherein the rule set at least includes a code structure and an exclusion list; The initialization unit is used to initialize the exclusion list, obtain a target exclusion list corresponding to the development project, and perform tree conversion on the code structure to obtain a code tree corresponding to the development project.

8. The device according to claim 6, characterized in that The processing unit comprises: A code acquisition unit, used to acquire a target code corresponding to the token; An extraction unit is used to extract the package name corresponding to the token from the target code.

9. The device according to claim 6, characterized in that The inspection unit comprises: A third detection unit, configured to detect whether the imported module depends on other imported modules according to the dependency relationship corresponding to the imported module; a fourth detection unit, configured to detect whether the import module complies with a dependency rule if the import module depends on other import modules; A determination unit, configured to determine that the dependency relationship corresponding to the imported module does not meet the specification requirements if the imported module does not meet the dependency rule; The first ending unit is used to end the specification verification of the development project if the import module does not depend on other import modules or the import module meets the dependency rule.

10. The device according to claim 6, characterized in that Also includes: The second ending unit is used to end the specification verification of the development project if the module corresponding to the token exists in the target exclusion list, or the imported module exists in the target exclusion list, or the dependency relationship corresponding to the imported module meets the specification requirements.

Images