Code checking method and electronic equipment

Abstract

The invention discloses a code checking method and electronic equipment, and relates to the technical field of computers, and the method comprises the steps: carrying out full-dimensional code pre-checking before a code is submitted to a remote code warehouse, obtaining a temporary code which solves a large number of problems and has security assurance through multiple rounds of interactive decisions, solving the technical problem that the code checking process is tedious, and improving the code checking efficiency. The quality guarantee of the whole process from detection, optimization to submission before code submission is realized, and the efficiency and reliability of code delivery are greatly improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to a code checking method and an electronic device. BACKGROUND

[0002] In the field of software development, automatic code checking is a key link to guarantee code quality. Related code checking methods mostly rely on CI / CD tools (such as Jenkins), and the checking is triggered after the code is submitted to a remote repository. However, this kind of checking method has a lag, and if problems are found after submission, the developer must perform remote code rollback operation, modify locally, re-submit the code and trigger the checking again. This checking process is cumbersome and seriously slows down the development progress. SUMMARY

[0003] The present application provides a code checking method and an electronic device to at least solve the problem of cumbersome code checking process in the related art.

[0004] The present application provides a code checking method, comprising: obtaining first code of a target project to be submitted in a local cache; obtaining second code of the target project cached in a remote code repository; generating temporary code of the target project according to the first code and the second code, wherein the temporary code comprises all contents of the first code and the second code; checking the temporary code according to a pre-set code checking rule to generate a problem list; displaying a code obtaining identifier, the problem list and a code modification suggestion list corresponding to the problem list on a target interface; in response to a triggering operation of the code obtaining identifier, obtaining modified temporary code obtained according to the code modification suggestion list; in a case where the modified temporary code meets the code checking rule, submitting the modified temporary code to the remote code repository for caching.

[0005] The present application also provides a code checking device, comprising: a first obtaining unit configured to obtain first code of a target project to be submitted in a local cache; a second obtaining unit configured to obtain second code of the target project cached in a remote code repository; a code generating unit configured to generate temporary code of the target project according to the first code and the second code, wherein the temporary code comprises all contents of the first code and the second code; a code checking unit configured to check the temporary code according to a pre-set code checking rule to generate a problem list; The display unit is configured to display the code acquisition identifier, the problem list, and the code modification suggestion list corresponding to the problem list on the target interface. The third acquisition unit is configured to acquire the modified temporary code obtained according to the code modification suggestion list in response to a triggering operation of the code acquisition identifier. The code submission unit is configured to submit the modified temporary code to the remote code repository for caching in a case where the modified temporary code meets the code checking rule.

[0006] The present application also provides an electronic device, comprising a memory configured to store a computer program, and a processor configured to execute the computer program to implement the steps of the code checking method.

[0007] The present application also provides a computer readable storage medium, wherein the computer readable storage medium stores a computer program, and the computer program is executed by a processor to implement the steps of the code checking method.

[0008] The present application also provides a computer program product, comprising a computer program, and the computer program is executed by a processor to implement the steps of the code checking method.

[0009] The present application performs full-dimensional code pre-checking before submitting the code to the remote code repository, and obtains the temporary code with a large number of problems solved and safety guaranteed through multiple rounds of interactive decision-making, thereby solving the technical problem of complicated code checking process, realizing the whole process quality guarantee from detection, optimization to submission before code submission, and greatly improving the efficiency and reliability of code delivery, so as to solve the technical problem of complicated and low-efficiency code checking process, and achieve the technical effect of improving the code checking efficiency. BRIEF DESCRIPTION OF DRAWINGS

[0010] In order to more clearly illustrate the embodiments of the present application, the drawings needed in the embodiments will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0011] Figure 1 A flowchart of a code checking method provided by an embodiment of the present application; Figure 2 An interactive interface provided by an embodiment of the present application; Figure 3 An architecture diagram of a code checking system provided by an embodiment of the present application; Figure 4 A design diagram of a code checking system provided by an embodiment of the present application; Figure 5 A flowchart of a code inspection system according to an embodiment of the present application. DETAILED DESCRIPTION

[0012] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative work fall within the protection scope of the present application.

[0013] It should be noted that, in the description of the present application, the terms “comprise”, “contain” or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such a process, method, article or device. The terms “first”, “second” and the like in the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence.

[0014] In order for those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the drawings and specific embodiments.

[0015] In combination with the specific application environment architecture or specific hardware architecture on which the code inspection method is dependent, the specific application environment architecture or specific hardware architecture is described herein.

[0016] Before the present application is described in detail, a brief description of the professional field to which the present application pertains is provided, in which: SAST (Static Application Security Testing) is a software security analysis method that automatically identifies, locates and reports possible security defects, coding vulnerabilities, logical errors and code fragments that violate security policies in computer program code without actually executing the code by analyzing the syntax, structure, semantics and data flow or control flow of the original code, intermediate code or object code of the program.

[0017] CI / CD (Continuous Integration / Continuous Deployment) is a set of software development practices and methodologies based on automated processes, the core of which is to realize the rapid, reliable and frequent integration and release of code changes through a series of automated build, test and deployment stages.

[0018] PR (Pull Request) is a mechanism for developers to inform team members of the completed feature branches they wish to merge into the main branch in collaborative development. It is not only a request for merging operations, but also provides a centralized platform for code review, discussion, and continuous integration verification.

[0019] PEP8 (Python Enhancement Proposal 8) is an official Python code writing style guide co-written and maintained by Guido van Rossum, the creator of Python, and others. It is not a syntax specification, but a set of coding standards for code format, naming conventions, and comments. Its core purpose is to improve the readability and consistency of Python code, thereby ensuring its maintainability among a wide developer community.

[0020] CLI (Command Line Interface) is a text-based computer program interaction interface. Users input pre-defined text commands to a command line interpreter, which receives and parses the commands, directly calls the underlying functions of the operating system kernel or application to execute corresponding tasks, and feeds back the execution results or status information in text form to the user.

[0021] Currently, with the continuous development of software development technology, team collaboration development mode has become mainstream, and remote code repository (such as Git repository) has become the core carrier of code management. To ensure code quality, code inspection and code generation technology has emerged, from early manual code review, gradually developing into an automated inspection mode relying on Git Hooks, Jenkins, GitHub Actions, etc., aiming to reduce syntax errors, standardize code style, and reduce security risks. Related code inspection technology mainly realizes one-way flow by triggering inspection output results. Git Hooks can trigger local inspection at the code commit or push stage, and CI / CD continuous integration / continuous deployment tools can trigger cloud inspection after the code is committed to the remote repository. The inspection content focuses on syntax errors and basic code specifications, and relies on open source tools (such as pylint, checkstyle) to achieve direct submission or display of error messages without specific problem reports or lists. At the same time, in existing technologies, the interaction between users and inspection tools is mainly a one-way mode from user triggering to tool output, lacking dynamic response to user needs and safety control of tool execution, such as directly executing file modification operations without user confirmation.

[0022] Nowadays, the code inspection scheme based on CI / CD tools (such as Jenkins) is that after the developer submits the code to the remote repository through the "git commit and git push" command, the tool automatically pulls the complete code, builds a temporary environment, calls the pylint, checkstyle and other tools to detect syntax errors, compilation errors and the like, and finally only realizes the result closed loop of "directly submitting the repository" or "error reporting". But this scheme has obvious limitations, including the inability to generate an inspection report containing problem details and quality indicators, and the lack of any user-involved interactive links, such as tool execution confirmation and problem marking. Secondly, after the code is modified, the inspection needs to be triggered repeatedly through the whole process, and the inspection rules cannot be dynamically adjusted according to the code type and project stage, nor can the problem modification suggestions be provided. The specific problems are as follows: 1) Inspection lag: CI / CD tools trigger inspection only after the code is pushed to the remote repository. If a problem (such as dependency conflict) is found during inspection, the developer needs to first roll back the code from the remote repository, modify it locally and then resubmit, which is a cumbersome process that significantly increases development time; 2) Inspection limitations: Only the syntax and basic specifications of the local code to be submitted are checked, and the main branch code in the remote pull repository code is not merged, which cannot detect the problem of "incompatibility between the code to be submitted and the main branch interface", such as the modification of the main branch function parameters and the non-synchronous update of the calling method of the code to be submitted, resulting in the risk of code conflict after submission; 3) No modification suggestions and interactions: Only error information is output, and no modification suggestions are provided, so the developer needs to consult the specification documents or debug the code, especially for novice developers, which takes a long time to locate and fix the problem; and there is no multi-round interaction mechanism to adjust the inspection rules or repair methods according to the developer's needs; 4) Cache inefficiency: Complete repository code needs to be pulled every time for inspection, even if only a small number of files are modified. For large projects, the pull and environment building time is long, and it also occupies a large amount of server resources, affecting the inspection efficiency; 5) Version control tool processing problem limitations: Only responsible for code storage and branch management, without code quality pre-inspection function, cannot avoid the problem of "incompatibility between incremental code and main branch".

[0023] Embodiments of the present application provide a code inspection method, which takes an agent as the core driver. When the process start node is triggered, the user is guided to an interactive operation interface, without manual intervention in process connection. Finally, the whole process quality guarantee from detection to optimization before code submission is realized, which greatly improves the code delivery efficiency and reliability. The following embodiments describe the method in detail in combination with the execution process of the code inspection method.

[0024] Figure 1A flowchart of a code checking method provided by an embodiment of the present application is applied to a code checking system and specifically includes the following steps as shown in Figure 1 S101, obtaining first code of a target project to be submitted in a local cache.

[0025] Understandably, before the code is submitted to the remote code repository for caching, the first user triggers a code pre-checking process node (hereinafter referred to as node) through an interactive operation interface, for example, the first user clicks the "check & commit" button on the interface to trigger the process node. Subsequently, in response to the triggering operation of the node, the code to be submitted of the target project in the local cache or local space is read, the code to be submitted is recorded as the first code, and the first code is marked as a code file to be committed.

[0026] S102, obtaining second code of the target project cached in the remote code repository.

[0027] Understandably, in response to the triggering operation of the node, or after the first code is read, the second code of the target project cached in the remote code repository is pulled through the GitHub tool calling API. In one example, the second code can be submitted by a second user to the remote code repository for storage, and the first code is modified on the basis of the historical code before the second code. In this case, the first code includes new code, and the second code also includes new code, that is, the first code and the second code are partially the same. In another example, the second code is historical code, and the first code is modified on the basis of the second code. In this case, only the first code includes new code. Understandably, the target project can be completed by multiple users in collaboration, and multiple users can edit the code. Subsequent modifications are based on the latest code cached in the remote code repository to ensure the accuracy and uniqueness of the code.

[0028] S103, generating temporary code of the target project according to the first code and the second code.

[0029] The temporary code includes all contents of the first code and the second code.

[0030] Understandably, on the basis of the above and S101 and S102, the first code and the second code are integrated to generate complete temporary code of the target project, wherein the temporary code includes all contents of the first code and the second code, that is, the new code in the first code and the main branch code in the second code are merged to obtain the temporary code, so as to avoid the risk of local compliance but overall incompatibility of the code. In one example, the main branch function parameters in the second code are modified, and the generated temporary code is updated synchronously in the calling mode to avoid the risk of code conflict after code submission.

[0031] ​Optionally, according to the first code and the second code, the complete temporary code of the target project is generated, which can be achieved by the following steps: The incremental code of the target project is determined by comparing the first code and the second code through a target container assigned to the target project, wherein the target container is independent of the local cache and the remote code repository and is used to provide a dedicated code running environment for the target project, and the second code is the full code of the target project; and the complete temporary code of the target project is generated by integrating the first code and the incremental code through the target container.

[0032] It can be understood that the target container assigned to the target project is determined, and the target container can be understood as a Docker lightweight container. For the target project department, the target container provides an independent sandbox environment. When using the code checking system for the first time, the full code (i.e., the second code) of the remote master branch pulled through the Git API is built into the basic cache in the independent sandbox environment (i.e., the target container), and the cache version is recorded according to the commit ID of the master branch. Subsequently, the local cache version (i.e., the first code) and the latest version of the remote master branch (i.e., the second code) are compared in the target container, and only the incremental code corresponding to the version difference is pulled, for example, the newly added “utils.py” file and the modified “config.yaml” file of the master branch, and then the incremental code is merged with the first code to form the complete temporary code, i.e., the complete code of the target project is checked each time the local pre-check is performed. The second code is also the complete code or the full code of the target project.

[0033] It can be understood that the sandbox environment is isolated from the local space and the remote repository, and does not affect the original code. Through the standardized sandbox environment, the Docker image configuration is unified, including fixed versions of checking tools, dependent libraries and running environments, which ensures that the checking environments of all developers in the team are consistent, effectively solves the problem of poor environment consistency, and avoids the problem that the local pre-check is passed but the remote build fails after being submitted to the repository, for example, the problem of inconsistent versions of local dependent libraries and remote libraries.

[0034] It can be understood that the expired cache can be cleaned up regularly, for example, the cache that has not been used for more than 7 days or the cache corresponding to the master branch version that has been overwritten, to release the local storage space. At the same time, the developer can manually clean up the specified cache, and the old version cache can be deleted through the cache management interface of the IDE plug-in.

[0035] S104, checking the temporary code according to the pre-set code checking rule to generate a problem list.

[0036] The code checking rule includes at least one checking rule related to compliance, compatibility, security and running performance.

[0037] Understandably, on the basis of S103, the combined temporary code is subjected to pre-set code checking rules, and different checking levels call differentiated professional tools to output a structured problem list. Among them, the temporary code can be checked in all dimensions through the code checking rules, including compliance, compatibility, code performance, security, etc. to avoid the risk of partial compliance but overall incompatibility. In addition, the team administrator can configure the code checking rules through the Web console, such as customizing code specifications, security vulnerability level thresholds, performance pre-evaluation indicators, etc., and synchronizing them to the IDE plug-ins of all developers, achieving a balance between unified rules and personalized adaptation.

[0038] Optionally, the temporary code is checked according to the pre-set code checking rules to generate a problem list, which can be implemented through the following steps: The temporary code is subjected to basic compliance checking, wherein the basic compliance checking includes checking of syntax errors, code format and / or comment integrity; the incremental code and the original code in the temporary code are subjected to compatibility checking; the temporary code is subjected to security checking, wherein the security checking includes calculation of code complexity of the temporary code, checking of potential problems existing in the temporary code, and checking of security vulnerabilities existing in the temporary code by matching a standard vulnerability database; the temporary code is subjected to running performance evaluation to obtain a performance evaluation result; the code structure of the temporary code is subjected to deep analysis by a pre-trained language model for code scenarios to comb the association relationship, logical relationship and / or class definition between the code modules in the temporary code, and obtain an analysis result; a unit test adapted to the temporary code is generated based on the analysis result, and the running errors existing in the temporary code are verified by executing the unit test; and a structured problem list is generated according to the basic compliance checking result, the compatibility checking result, the security checking result, the performance evaluation result and / or the running errors.

[0039] Understandably, the temporary code is subjected to basic compliance checking, specifically, the Pyright (Python) / Checkstyle (Java) tool is called to check syntax errors, code format (such as PEP8, Google JavaStyle), comment integrity, etc. of the temporary code, and other tools that can be called are not limited.

[0040] Optionally, the incremental code and the original code in the temporary code are subjected to compatibility checking, which can be implemented through the following steps: The interface matching degree of the incremental code and the original code in the temporary code is analyzed, wherein the interface matching degree includes function parameter and / or data type related matching degree; the dependency tree of the temporary code is parsed to check the dependency conflict between the incremental code and the original code, wherein the dependency conflict includes interface conflict between databases depended by the code.

[0041] It can be understood that the compatibility of the temporary code is checked, and the compatibility checking result is generated. Specifically, the interface matching degree of the incremental code and the original code is analyzed, for example, whether they are consistent in function parameters and / or data types, etc. The pip-audit (Python) / Maven Dependency Check (Java) tool is called to check the version compatibility of the dependent packages between the new code and the original code, wherein the temporary code includes the new code and the original code. At the same time, by parsing the temporary code dependency tree (pipdeptree), the indirect dependency conflicts between the new code and the original code are detected, for example, the new code depends on A library version 1.0, the original code depends on B library version 2.0, and A library version 1.0 and B library version 2.0 exist interface conflicts. The conflict path in the code can be recorded in the output problem list and a solution is provided, for example, the solution is "suggesting to upgrade A library to version 2.0, compatible with B library version 2.0".

[0042] It can be understood that the quality and safety of the temporary code are checked, and the security checking result is generated. Specifically, the code complexity is calculated by the Cyclomatic Complexity algorithm, and the potential BUG (vulnerability) is detected by calling the Sonarqube, Sentry tool, and matching the CVE database to check the security vulnerabilities, for example, SQL injection, hard-coded password, etc.

[0043] Optionally, the performance of the temporary code is evaluated to obtain a performance evaluation result, which can be realized by the following steps: Based on the code complexity and the execution time of at least one statement of the key function in the temporary code, the execution time of the key function in the standard environment is estimated by the pre-established quantitative evaluation model; at the same time, the memory leak risk existing in the running of the temporary code is checked, wherein the performance evaluation result includes the execution time and the memory leak risk.

[0044] It can be understood that the performance of the temporary code is pre-evaluated, and the performance evaluation result is generated. Specifically, based on static code analysis, the execution time of the key function in the temporary code is estimated, and the memory leak risk is detected, for example, unclosed file stream, unreleased object reference, etc. For the estimation of the execution time, a quantitative evaluation model can be established, based on the code complexity and the execution time statistics of at least one statement of the key function, for example, the number of loops, file IO operations, etc., to estimate the execution time of the key function in the standard environment, and to suggest optimization of the loop logic based on the execution time.

[0045] It can be understood that the pre-constructed large model automatically analyzes the problems of the temporary code and performs testing to determine the running problems of the temporary code. Specifically, a large model specially designed for the code scene (for example, Qwen3-Coder-30B-A3B) is used to first perform in-depth analysis on the code structure of the entire temporary code, sort out the key information such as the association between the modules in the temporary code, the code logic, and the definition of the class, and then generate a targeted unit test based on the analysis result. Finally, it is verified through the execution of the unit test whether the temporary code has running errors, so as to ensure that the code can be normally executed.

[0046] S105, displaying the code acquisition identifier, the problem list, and the code modification suggestion list corresponding to the problem list on the target interface.

[0047] It can be understood that the target interface is an interactive operation interface, which can also be understood as an IDE plug-in interface. The problem list and the code modification suggestion list corresponding to the problem list are displayed on the target interface, and the target interface supports the operation of the developer. Subsequently, the user can perform multiple rounds of modification and pre-checking operations based on the target interface, that is, to solve the single problem of interaction, a multi-round dynamic interaction mechanism is established to support the developer to adjust the modification suggestion according to the demand, thereby reducing the decision cost. At the same time, an interactive process of user confirmation and tool execution is constructed to avoid tool misoperation, for example, mis-modification of core code files.

[0048] Optionally, before displaying the code acquisition identifier, the problem list, and the code modification suggestion list corresponding to the problem list on the target interface, the method further comprises: classifying and grading at least one problem in the problem list, wherein the problem level includes a blocking level, an optimization level, and a prompt level, the blocking level problem includes a syntax error problem, a compatibility conflict problem, a variable error problem, and / or a running error problem, the optimization level problem includes a code redundancy problem and / or an annotation missing problem, and the prompt level problem includes a code style difference problem; and generating the code modification suggestion list according to the classification and grading result of the at least one problem.

[0049] It can be understood that after the problem list is generated, the problem list is classified and graded to determine the problem type and the problem level of at least one problem included in the problem list. The problem level includes a blocking level, an optimization level, and a prompt level, the blocking level problem includes a syntax error problem, a compatibility conflict problem, a variable error problem, and / or a running error problem, the optimization level problem includes a code redundancy problem and / or an annotation missing problem, and the prompt level problem includes a code style difference problem, wherein the processing priority of the diagnosis level is higher than that of the optimization level and the prompt level. Subsequently, a large model is called to generate a differential suggestion for at least one problem to obtain a code modification suggestion list. The rules of the differential suggestion, that is, the setting of the prompt words of the large model, are described in the following embodiments.

[0050] Optionally, according to the classification and grading result of at least one problem, a code modification suggestion list is generated, which can be achieved by the following steps: For a blocking level problem, a one-key repair script is generated, wherein the one-key repair script includes the target code to be modified, the location of the target code in the temporary code, and the modified target code; for an optimization level problem, at least one code optimization scheme is generated, and the advantages of the at least one code optimization scheme and the differences between different code optimization schemes are marked; for a prompt level problem, a code optimization suggestion is generated; wherein the code modification suggestion list includes the one-key repair script, the at least one code optimization scheme and the code optimization suggestion.

[0051] Understandably, if it is a blocking level problem, a one-key repair script is provided, which contains the code file to be modified, the location of the problem code, and the modified code, for example, automatically completing the missing semicolon, correcting the function parameter type, etc. If it is an optimization level problem, multiple optional optimization schemes can be provided, and the advantages and differences of each scheme are marked in detail, for example, "Scheme A: Simplify the loop logic, reduce 20% code lines; Scheme B: Replace with Apache Commons tool class, improve 15% execution efficiency", etc. If it is a prompt level problem, only the code optimization suggestion needs to be output, for example, it is suggested to add function function comment, and the code is not forced to be modified.

[0052] Understandably, for multiple optional optimization suggestion schemes, effect preview can also be performed. Specifically, for optimization level problems, such as code redundancy, performance bottleneck, etc., a comparison report before and after modification is output synchronously when generating the suggestion, which can include quantitative data such as code line number change, execution efficiency improvement ratio, resource occupation reduction amount, etc. An example, the original code is "using for loop to traverse the list to filter data, code line number is 15, estimated execution time is 80ms, memory occupation is 5MB". Optimization suggestion scheme A is "using Python list comprehension optimization, code line number is 5, estimated execution time is 30ms (improving 62.5%), memory occupation is 3MB (reducing 40%)". Optimization suggestion scheme B is "using pandas library filter function optimization, code line number is 3, estimated execution time is 20ms (improving 75%), memory occupation is 2MB (reducing 60%), and pandas dependency needs to be added". The user can select the code modification strategy according to the displayed optimization suggestion scheme.

[0053] Understandably, the user can also make personalized adaptation, adjust the display priority of multiple sets of optional optimization suggestion schemes. Specifically, the developer's past 1-2 months of code submission style, modification selection data are provided as context to the large model, so that it understands user preferences and code style, and adjusts the display priority of each suggestion scheme according to its preferences, for example, the developer's historical preference "performance first", then recommend performance optimization scheme. At the same time, it contains "team specification adaptation", which supports team administrators to upload custom code specifications on the web console, such as "backend code must contain function parameter comments" and "frontend code prohibits using var to declare variables". Subsequently, the custom code specifications can be converted into prompt words for the large model, such as "the generated suggestions must meet: function definitions must be followed by parameter explanations in the format "@param, variable name, type, explanation", etc., to ensure that the suggestions meet the team's unified requirements. This effectively improves the adoption rate of personalized suggestions, and developers do not need to remember complex specifications, but can complete optimization through visual interaction, and the development experience satisfaction will also be improved.

[0054] S106, in response to the triggering operation of the code acquisition identifier, acquiring the modified temporary code obtained according to the code modification suggestion list.

[0055] Understandably, on the basis of the above S105, after the user completes the modification of the temporary code based on the code modification suggestion list, the code acquisition identifier displayed in the target interface is triggered. In response to the triggering operation of the code acquisition identifier, the modified temporary code is acquired. Subsequently, the modified temporary code is continuously checked according to the code checking rule.

[0056] Optionally, the processing priority of the blocking level problem is higher than that of the optimization level problem and the prompt level problem, the processing priority of the optimization level problem can be higher than that of the prompt level problem, or the processing priority of the optimization level problem can be the same as that of the prompt level problem, which is not limited here.

[0057] Optionally, in response to the triggering operation of the code acquisition identifier, the modified temporary code obtained according to the code modification suggestion list is acquired, which can be realized by the following steps: In the case that the problem list exists a blocking level problem, in response to a trigger operation of a one-key repair mark or a custom modification mark in the target interface, a one-key repair script is executed or a code modification interface is displayed, wherein the code modification interface includes a temporary code; in response to a trigger operation of a code acquisition mark, the modified temporary code is acquired; the modified temporary code is checked according to the code checking rule to generate a next problem list; if the next problem list does not exist a blocking level problem, it is judged whether the next problem list exists an optimization level problem or a prompt level problem; in the case that the next problem list exists an optimization level problem, at least one code optimization scheme and a scheme selection mark are displayed in the target interface; in response to a trigger operation of the scheme selection mark, a code optimization scheme corresponding to the scheme selection mark is executed; or in the case that the next problem list exists a prompt level problem, in response to a trigger operation of an ignore mark in the target interface, the prompt level problem is ignored; in response to a trigger operation of the code acquisition mark, the modified temporary code is acquired, and the modified temporary code is continuously checked according to the code checking rule until the modified temporary code meets the code checking rule.

[0058] Understandably, the problem list includes blocking level problems, optimization level problems and / or prompt level problems, which can be processed in order of processing priority. An example, in the case of an initial problem list generated for the initial temporary code includes blocking level problems, a one-key repair solution and a one-key repair identifier or a custom modification identifier are displayed on the target interface, and in response to the triggering operation of the one-key repair identifier or the custom modification identifier, a one-key repair script is executed or a code modification interface is displayed for user custom modification. Subsequently, the first temporary code modified for the blocking level problem is obtained, and the full-dimensional check of the first temporary code is continued, and the next problem list is generated. Understandably, the next problem list is different from the initial problem list, that is, modifying the blocking level problem can affect the optimization level problem and / or the prompt level problem, that is, the one-key repair script can modify all or at least part of the level problem at a time. If the next problem list does not exist blocking level problem, it is judged whether the next problem list exists optimization level problem or prompt level problem, if the next problem list still exists blocking level problem, continue one-key repair or custom modification until the problem list does not exist blocking level problem. In the case of the next problem list existing optimization level problem, at least one code optimization solution and a solution selection identifier are displayed in the target interface, and a personalized priority can also be displayed, or the user can also propose an objection, and the subsequent identification of the user's demand re-generates the optimization suggestion solution. Understandably, the number of interactions can also be set, for example, the upper limit of the number of rounds of interaction is 5 times, if the user still does not confirm the optimization solution after 5 times of interaction, the "forced submission" or "custom modification" can be selected, and at the same time the risk prompt is recorded and the second authorization is required, avoiding unlimited generation of optimization suggestion solutions according to the user's demand. In response to the triggering operation of the solution selection identifier, the code optimization solution corresponding to the solution selection identifier is executed. Or, in the case of the next problem list existing prompt level problem, in response to the triggering operation of the ignore identifier in the target interface, the prompt level problem is ignored, or the modification solution about the prompt level problem is executed. After completing the modification, in response to the triggering operation of the code acquisition identifier, the second temporary code modified is obtained, and the third temporary code is continuously subjected to full-dimensional check according to the code checking rule until the third temporary code meets the code checking rule.

[0059] Understandably, after the blocking level problem is solved, the optimization level problem and the prompt level problem can be selectively solved according to the demand, or directly ignored.

[0060] It can be understood that when the problem list is displayed on the target interface, viewing the problem details is also supported, for example, clicking on the problem entry in the problem list jumps to the corresponding code line in the temporary code, and the problem cause is displayed. When selecting the optimization scheme in the target interface, for the optimization level problem, the target scheme can be checked, and for the blocking level problem, "one-key repair" or "customized modification" can be selected. The user can also object to the optimization scheme, and if the suggestion in the optimization scheme is refused, the reason for refusal can be input, for example, "the suggested modification logic conflicts with business requirements". Subsequently, the demand intention is identified according to the objection input by the user, and the secondary optimization suggestion generation is triggered. At the same time, the above process also supports the "step-by-step confirmation" of the developer, and the unconfirmed problems are automatically saved to the local cache and automatically loaded next time the program is started.

[0061] It can be understood that the target interface also has the functions of batch operation and code inspection rule saving. Specifically, in one inspection, the developer can perform batch operations on similar problems, such as "one-key repair of all PEP8 specification problems" and "ignore all prompt level style difference problems". At the same time, the developer is allowed to save personalized operation rules, such as "automatically ignore'missing comments' type prompt level problems every time the program is checked", which can be automatically applied next time the program is checked, reducing repeated operations.

[0062] It can be understood that the target interface also supports multi-person collaborative interaction. For team collaboration scenarios, when the code to be submitted involves code modules maintained by multiple developers, for example, the "user authentication module" is maintained by two developers A and B. In this case, the code module leader is identified and a collaboration request is sent, for example, through IDE notification or enterprise WeChat message, email, etc. The code module leader can view the code to be submitted and the inspection results, and add comments, for example, "suggest keeping the original authentication logic and modifying the parameter verification method", and the developer needs to adjust the scheme in combination with the opinions of multiple parties before submitting, avoiding collaboration conflicts caused by single modification.

[0063] The target interface includes an overview layer, a detail layer, and an operation layer.

[0064] Optionally, the problem list and the code modification suggestion list corresponding to the problem list are displayed on the target interface, which can be achieved by the following steps: The total number of problems involved in the problem list, the proportion of problems at each level, and / or the inspection pass rate are displayed on the overview layer; the problem list is displayed on the detail layer, wherein the problem list includes problem type, code location of the target code where the problem exists, problem level, and / or problem summary; the code acquisition identifier, the code viewing identifier, the code modification suggestion identifier, the customized modification identifier, and the ignore identifier are displayed on the operation layer, wherein the code viewing identifier is used to identify the target code, and the code modification suggestion identifier is used to identify the code modification suggestion list corresponding to the problem list.

[0065] Understandably, the IDE plug-in interface can adopt a hierarchical display design. Specifically, the target interface includes an overview layer, a detail layer, and an operation layer, wherein the overview layer is used to display the total number of problems, the proportion of problems at each level, for example, 2 blocking level problems, 5 optimization level problems, 3 prompt level problems, and the check pass rate, for example, "current pass rate 60%, after fixing the blocking level problem, it can be submitted". The detail layer is used to display the problem list, which supports expanding the specific problem list, for example, problem type, code location, severity, and brief description, etc., and also supports filtering problems by "file path" and "problem type" to quickly locate key problems. The operation layer is used to provide four operation buttons of "view code", "apply suggestion", "custom modification", and "ignore" for each problem. Clicking "view code" can jump to the corresponding code line in the sandbox environment, highlight the problem position and pop up the reason explanation, for example, "the function add_user() parameter num type is int, and the submitted code transmits str type, which is incompatible with the main branch interface", and clicking "ignore" can ignore the optimization level problem and / or the prompt level problem.

[0066] Exemplary, Figure 2 An interactive interface schematic diagram provided by the embodiment of the present application is shown. The left side of the interactive interface is the overview layer, which shows the total number of problems, the proportion of problems at each level, and the check pass rate. The right side of the interactive interface includes the detail layer and the operation layer, wherein the detail layer shows the specific problem list and provides a search window for detail tracking. The operation layer shows the code acquisition identifier, the code viewing identifier, the code modification suggestion identifier, the custom modification identifier, and the ignore identifier.

[0067] S107, in the case that the modified temporary code meets the code checking rules, the modified temporary code is submitted to the remote code repository for caching.

[0068] Understandably, on the basis of the above S106, the developer confirmation scheme is executed, the code is modified in the temporary code, the full-dimension check is re-performed, and the modification effect is verified to ensure that no new problem is generated, that is, the modified temporary code meets the code checking rule verification. After the pre-check passes, the modified temporary code is submitted to the remote code repository by the developer authorization, that is, clicking the "confirm submission" button in the IDE plug-in interface (target interface), and a submission report is generated synchronously, wherein the submission report includes the problem quantity, the number of adopted suggestions, the modification content, etc. to the repository submission log. After the code is submitted to the repository, the regular check process is triggered automatically, which greatly improves the pass rate of the regular check on the basis of the pre-check, thereby reducing the rollback times, shortening the code checking process, and improving the code submission success rate.

[0069] The code inspection method provided by the disclosure is driven by an agent to drive a code pre-inspection process and a multi-round interactive decision-making process, without manual intervention in process connection, realizing whole-process quality guarantee from detection and optimization to formal submission before code submission, and greatly improving the efficiency and reliability of code delivery. Specifically, through the collaborative design of an independent sandbox and code incremental caching, the to-be-submitted code and the main branch code are merged in the independent sandbox, the consistency of the code running environment is guaranteed, and the incremental caching and its life cycle management are supported, the standardized sandbox environment ensures that the inspection tool version, dependent library configuration and running environment of all developers in the team are consistent, and the success rate of cross-environment code submission is effectively improved. The design of the full-dimension code inspection rule includes a combination scheme of multi-layer inspection of basic compliance, compatibility, quality safety, performance pre-evaluation, running test and differentiated tool calling logic of different levels, covers a large number of common problems, comprehensively reduces the online bug rate, and effectively improves the security vulnerability detection rate. Based on the differentiated suggestion generation of the problem level and the developer preference, the code modification suggestion list is generated, the practicality and developer adoption rate of the suggestion are effectively improved, the code review labor cost is reduced, and the later bug repair cost is also reduced, and the online troubleshooting time is also reduced. Through the construction of a multi-round dynamic interactive system of developer leading and system responding, the operation efficiency and risk controllability are considered, and the developer objection processing, demand intention recognition and secondary suggestion generation are also supported, the personalized suggestion adoption rate is improved, and the developer does not need to remember complex specifications, and the code optimization can be completed through visual interaction, further improving the development experience satisfaction. There are also risk prompts and secondary authorizations, such as “forced submission” requiring secondary confirmation, to ensure that the developer is aware of the potential impact of the un-fixed problem, and to reduce the risk of online failure. In summary, the disclosure realizes the automatic process of code pre-inspection and submission, greatly reduces the human review cost, improves the work efficiency, and helps the intelligent transformation of the process work.

[0070] On the basis of the above-mentioned embodiments, Figure 3 The code inspection system provided by the embodiments of the disclosure has the architecture shown in the figure, and the code inspection system comprises a temporary cache construction module, a full-dimension code inspection module, a modification suggestion generation module, an interactive decision-making module and an automatic execution and submission module.

[0071] The core driving layer of the code inspection system based on the agent executes the following processes: a trigger node, a temporary cache construction, a full-dimension code inspection, intelligent optimization suggestion generation, interactive decision-making, automatic execution and submission, and remote repository synchronization, wherein, The temporary cache construction module is configured to: acquire first code of a target project to be submitted in a local cache; acquire second code of the target project cached in a remote code repository; and generate a temporary code of the target project according to the first code and the second code, wherein the temporary code comprises all contents of the first code and the second code.

[0072] It can be understood that the execution process of the temporary cache construction module is code pulling, sandbox environment, temporary code merging, cache management and outputting temporary code. The specific implementation process of each step is described in the above embodiment and will not be repeated here.

[0073] The full-dimension code checking module is configured to check the temporary code according to the pre-set code checking rule, and generate a problem list.

[0074] It can be understood that the execution process of the full-dimension code checking module is basic compliance checking syntax format, compatibility checking dependency conflict, quality and safety checking security vulnerability, performance evaluation test, integrating various checking results, and generating a problem list.

[0075] The suggestion generation module is configured to classify and process at least one problem in the problem list, wherein the problem level includes a blocking level, an optimization level and a prompt level, the blocking level problem includes a syntax error problem, a compatibility conflict problem, a variable error problem and / or a running error problem, the optimization level problem includes a code redundancy problem and / or an annotation missing problem, and the prompt level problem includes a code style difference problem; and generate a code modification suggestion list according to the classification and grading result of the at least one problem.

[0076] It can be understood that the execution process of the suggestion generation module is problem grading, suggestion generation, scheme generation, personalized adaptation and output suggestion.

[0077] The interactive decision module is configured to display the code acquisition identifier, the problem list and the code modification suggestion list corresponding to the problem list on the target interface.

[0078] It can be understood that the execution process of the interactive decision module is interface display, developer operation, collaboration management and output scheme.

[0079] The automatic execution and submission module is configured to obtain modified temporary code obtained according to the code modification suggestion list in response to the triggering operation of the code acquisition identifier; and submit the modified temporary code to the remote code repository for caching in the case that the modified temporary code meets the code checking rule.

[0080] It can be understood that the execution process of the automatic execution and submission module is scheme execution, secondary checking, authorized submission, report generation and repository synchronization.

[0081] It can be understood that the specific implementation steps of each module in the code checking system are described in the above embodiment and will not be repeated here.

[0082] The intelligent code submission pre-check and interactive optimization system (i.e., the code checking system) provided by the embodiment has a core component of CodePreCheck Agent (an intelligent agent for pre-checking code submission). The intelligent agent can be seamlessly integrated into an IDE plug-in such as VS Code, and is overall constructed based on a Qwen3-30B-A3B large model. The intelligent agent makes decisions and calls tools to automatically promote and complete tasks by autonomously completing thinking and reasoning through the large model.

[0083] On the basis of the above embodiment, Figure 4 The design diagram of the code checking system provided by the embodiment includes a trigger node, an intelligent agent, a large model, context data, a remote code repository, a tool, an interactive interface, an email, and a webpage. The code checking system is driven by the intelligent agent as the core. When the trigger node is triggered, the system automatically guides the user to enter the interactive interface without manual intervention in process connection. Through data interaction with the large model, the remote repository, and the tool, the system realizes quality assurance in the whole process from detection, optimization to submission before code submission.

[0084] On the basis of the above embodiment, Figure 5 The flowchart of the code checking system provided by the embodiment specifically includes the following steps as shown in Figure 5 1) The developer triggers the submission process in the interactive interface; 2) a temporary cache construction module generates a complete temporary project (temporary code); 3) a full-dimension code checking module performs checking; 4) there are blocking-level problems; 5) a suggestion generation module outputs a one-key repair solution; 6) the developer selects to perform repair or customize modification; 7) step 2) is re-executed; 8) there are optimization-level or prompt-level problems; 9) an intelligent suggestion generation module outputs multiple selectable solutions and individualized priorities; 10) the developer interacts with the interactive decision module to select a solution or raise an objection; 11) the developer selects; 12) the system recognizes the demand to generate a secondary suggestion; 13) an automatic execution and submission module performs modification; 14) full-dimension checking is re-executed; 15) it is checked whether the checking is passed; 16) the developer authorizes code submission to be pushed to a remote repository; 17) step 13) is re-executed; and 18) a submission report is generated and synchronized to a repository log.

[0085] It can be understood that the specific implementation of the above steps is described with reference to the above embodiment, which is not repeated here.

[0086] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiment can be realized by means of software and a general hardware platform as necessary, and of course it can also be realized by hardware, but in many cases the former is a better embodiment.

[0087] ​The embodiment of the application further provides a code checking device, wherein a first obtaining unit is configured to obtain first code of a target project to be submitted in a local cache; a second obtaining unit is configured to obtain second code of the target project cached in a remote code repository; a code generating unit is configured to generate temporary code of the target project according to the first code and the second code, wherein the temporary code comprises all contents of the first code and the second code; a code checking unit is configured to check the temporary code according to a preset code checking rule, and generate a problem list; a display unit is configured to display, on a target interface, a code obtaining identifier, the problem list and a code modification suggestion list corresponding to the problem list; a third obtaining unit is configured to obtain modified temporary code obtained according to the code modification suggestion list in response to a triggering operation of the code obtaining identifier; a code submitting unit is configured to submit the modified temporary code to the remote code repository for caching in a case where the modified temporary code meets the code checking rule.

[0088] Optionally, the code generating unit is configured to: determine incremental code of the target project by comparing the first code and the second code through a target container assigned to the target project, wherein the target container is independent of the local cache and the remote code repository, and is configured to provide a dedicated code running environment for the target project, and the second code is full code of the target project; integrate the first code and the incremental code through the target container to generate complete temporary code of the target project.

[0089] Optionally, the code checking rule comprises at least one checking rule related to compliance, compatibility, security and running performance.

[0090] Optionally, the code checking unit is configured to: perform basic compliance checking on the temporary code, wherein the basic compliance checking comprises checking related to syntax error, code format and / or annotation integrity; perform compatibility checking on the incremental code and original code in the temporary code; perform security checking on the temporary code, wherein the security checking comprises calculation of code complexity of the temporary code, checking of potential problems existing in the temporary code and checking of security vulnerabilities existing in the temporary code by matching a standard vulnerability database; perform running performance evaluation on the temporary code to obtain a performance evaluation result; The code structure of the temporary code is deeply analyzed by using a pre-trained language model tailored to the code scenario. The relationships, logical connections, and / or class definitions between the various code modules in the temporary code are identified, and the analysis results are obtained. Based on the analysis results, unit tests adapted to the temporary code are generated, and the runtime errors in the temporary code are verified by executing the unit tests. Based on the results of basic compliance checks, compatibility checks, security checks, performance assessments, and / or runtime errors, a structured list of issues is generated.

[0091] Optionally, the code inspection unit is used for: Analyze the interface matching degree between the incremental code in the temporary code and the original code, where the interface matching degree includes the matching degree related to function parameters and / or data types; Parse the dependency tree of the temporary code and check for dependency conflicts between the incremental code and the original code. These dependency conflicts include interface conflicts between the databases that the code depends on.

[0092] Optionally, the code inspection unit is used for: Using a pre-established quantitative evaluation model, the execution time of the critical function in a standard environment is estimated based on code complexity and the execution time of at least one statement constituting the critical function in temporary code; simultaneously, Check for memory leak risks in running temporary code. The performance evaluation results include execution time and memory leak risk.

[0093] Optionally, the code inspection device is also used for: At least one problem in the problem list is classified and graded, where the problem level includes blocking level, optimization level and prompting level. Blocking level problems include syntax error problems, compatibility conflict problems, variable error problems and / or runtime error problems. Optimization level problems include code redundancy problems and / or missing comments problems. Prompting level problems include code style difference problems. Based on the classification and grading results of at least one problem, generate a list of code modification suggestions.

[0094] Optionally, the code inspection device is also used for: For blocking-level issues, a one-click repair script is generated. The one-click repair script includes the target code that needs to be modified, the location of the target code in the temporary code, and the modified target code. For optimization-level problems, generate at least one code optimization solution, and indicate the advantages of at least one code optimization solution and the differences between different code optimization solutions; For prompt-level issues, generate code optimization suggestions; The code modification suggestion list includes a one-click repair script, at least one code optimization solution, and code optimization suggestions.

[0095] Among them, blocking-level problems should be handled with higher priority than optimization-level and prompt-level problems.

[0096] Optionally, the third acquisition unit is used for: If there are blocking-level issues in the issue list, in response to the triggering operation of the one-click repair icon or the custom modification icon in the target interface, execute the one-click repair script or display the code modification interface, where the code modification interface includes temporary code; In response to a trigger action that retrieves the code retrieval identifier, retrieve the modified temporary code; The modified temporary code is checked according to the code inspection rules, and the next issue list is generated; If the next issue list does not contain any blocking-level issues, then determine if the next issue list contains any optimization-level or prompt-level issues. If an optimization-level issue exists in the next issue list, display at least one code optimization solution and a solution selection indicator on the target interface; in response to the triggering action of the solution selection indicator, execute the code optimization solution corresponding to the solution selection indicator; or, If a prompt-level issue exists in the next issue list, respond to the trigger action of the ignore flag in the target interface and ignore the prompt-level issue; In response to the triggering operation of the code retrieval identifier, the modified temporary code is retrieved, and the modified temporary code is further checked according to the code inspection rules until the modified temporary code meets the code inspection rules.

[0097] The target interface includes an overview layer, a details layer, and an operation layer.

[0098] Optionally, the display unit is used for: The overview layer displays the total number of issues involved in the issue list, the percentage of issues at each level, and / or the pass rate. The details layer displays a list of issues, which includes the issue type, the code location of the target code with the issue, the issue level, and / or an issue overview. The operation layer displays code acquisition identifier, code viewing identifier, code modification suggestion identifier, custom modification identifier, and ignore identifier. Among them, the code viewing identifier is used to identify the target code, and the code modification suggestion identifier is used to identify the code modification suggestion list corresponding to the issue list.

[0099] For a description of the features in the embodiment corresponding to the code inspection device, please refer to the relevant description of the embodiment corresponding to the code inspection method, which will not be repeated here.

[0100] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the code inspection method embodiments described above.

[0101] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the code inspection method embodiments described above at runtime.

[0102] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0103] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the code inspection method embodiments described above.

[0104] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the code inspection method embodiments described above.

[0105] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0106] The code checking method provided in this application has been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A code inspection method, characterized in that, include: Retrieve the first code of the target project to be submitted from the local cache; Retrieve the second code of the target project cached in a remote code repository; Based on the first code and the second code, temporary code for the target project is generated, wherein the temporary code includes all the contents of the first code and the second code; The temporary code is inspected according to pre-defined code inspection rules, and a list of issues is generated. The target interface displays the code acquisition identifier, the problem list, and the corresponding code modification suggestion list. In response to the triggering operation of the code acquisition identifier, obtain the modified temporary code obtained according to the code modification suggestion list; If the modified temporary code complies with the code inspection rules, the modified temporary code will be submitted to the remote code repository for caching.

2. The method according to claim 1, characterized in that, The step of generating complete temporary code for the target project based on the first code and the second code includes: The incremental code of the target project is determined by comparing the first code and the second code with the target container assigned to the target project. The target container is independent of the local cache and the remote code repository and is used to provide a dedicated code execution environment for the target project. The second code is the full code of the target project. The first code and the incremental code are integrated through the target container to generate the complete temporary code for the target project.

3. The method according to claim 1, characterized in that, The code inspection rules include at least one inspection rule related to compliance, compatibility, security, and runtime performance. The temporary code is inspected according to the pre-defined code inspection rules to generate a list of issues, including: The temporary code is subjected to basic compliance checks, which include checks related to syntax errors, code formatting, and / or comment integrity. Perform a compatibility check between the incremental code and the original code in the temporary code; The temporary code is subjected to a security check, which includes calculating the code complexity of the temporary code, checking for potential problems in the temporary code, and checking for security vulnerabilities in the temporary code by matching a standard vulnerability database. The temporary code was subjected to a performance evaluation, and the performance evaluation results were obtained. The code structure of the temporary code is deeply analyzed by using a pre-trained language model tailored to the code scenario. The relationships, logical relationships, and / or class definitions between the various code modules in the temporary code are analyzed to obtain the analysis results. Based on the analysis results, unit tests adapted to the temporary code are generated, and the execution of the unit tests is used to verify the runtime errors in the temporary code. Based on the results of the basic compliance check, compatibility check, security check, performance evaluation, and / or runtime errors, a structured list of issues is generated.

4. The method according to claim 3, characterized in that, The compatibility check between the incremental code and the original code in the temporary code includes: Analyze the interface matching degree between the incremental code and the original code in the temporary code, wherein the interface matching degree includes the matching degree related to function parameters and / or data types; The dependency tree of the temporary code is parsed, and dependency conflicts between the incremental code and the original code are checked. The dependency conflicts include interface conflicts between the databases that the code depends on.

5. The method according to claim 3, characterized in that, The performance evaluation of the temporary code, to obtain the performance evaluation results, includes: Using a pre-established quantitative evaluation model, based on the code complexity and the execution time of at least one statement constituting the key function in the temporary code, the execution time of the key function in a standard environment is estimated; simultaneously, Check for memory leak risks in running the temporary code, wherein the performance evaluation results include the execution time and the memory leak risk.

6. The method according to claim 1, characterized in that, Before displaying the code acquisition identifier, the issue list, and the corresponding code modification suggestion list on the target interface, the method further includes: At least one problem in the problem list is classified and graded, wherein the problem level includes blocking level, optimization level and prompting level. Blocking level problems include syntax error problems, compatibility conflict problems, variable error problems and / or runtime error problems. Optimization level problems include code redundancy problems and / or missing comments problems. Prompting level problems include code style difference problems. Based on the classification and grading results of the at least one of the problems, a list of code modification suggestions is generated.

7. The method according to claim 6, characterized in that, The step of generating a code modification suggestion list based on the classification and grading results of the at least one problem includes: For the aforementioned blocking-level problem, a one-click repair script is generated, wherein the one-click repair script includes the target code that needs to be modified, the position of the target code in the temporary code, and the modified target code; For the optimization level problem, generate at least one code optimization solution, and indicate the advantages of the at least one code optimization solution and the differences between different code optimization solutions; For prompt-level issues, generate code optimization suggestions; The code modification suggestion list includes the one-click repair script, the at least one code optimization scheme, and the code optimization suggestions.

8. The method according to claim 7, characterized in that, The blocking-level issues have a higher processing priority than the optimization-level issues and the prompting-level issues. The response to the triggering operation of the code acquisition identifier, obtaining the modified temporary code based on the code modification suggestion list, includes: If the blocking-level problem exists in the problem list, in response to the triggering operation of the one-click repair icon or the custom modification icon in the target interface, the one-click repair script is executed or the code modification interface is displayed, wherein the code modification interface includes the temporary code; In response to the trigger operation of the code acquisition identifier, the modified temporary code is acquired; The modified temporary code is inspected according to the code inspection rules to generate the next issue list; If the next issue list does not contain any blocking-level issues, then determine whether the next issue list contains any optimization-level issues or prompt-level issues. If the optimization-level issue exists in the next issue list, at least one code optimization scheme and a scheme selection identifier are displayed on the target interface; in response to a trigger operation of the scheme selection identifier, the code optimization scheme corresponding to the scheme selection identifier is executed; or, If the prompt-level issue exists in the next issue list, the prompt-level issue is ignored in response to the triggering operation of the ignore flag in the target interface; In response to the triggering operation of the code acquisition identifier, the modified temporary code is acquired, and the modified temporary code is further inspected according to the code inspection rules until the modified temporary code conforms to the code inspection rules.

9. The method according to claim 1, characterized in that, The target interface includes an overview layer, a details layer, and an operation layer. Displaying the issue list and the corresponding code modification suggestion list on the target interface includes: The overview layer displays the total number of issues involved in the issue list, the percentage of issues at each level, and / or the pass rate of the inspection. The issue list is displayed in the details layer, wherein the issue list includes the issue type, the code location of the target code with the issue, the issue level, and / or an issue overview; The operation layer displays a code acquisition identifier, a code viewing identifier, a code modification suggestion identifier, a custom modification identifier, and an ignore identifier. The code viewing identifier is used to identify the target code, and the code modification suggestion identifier is used to identify the code modification suggestion list corresponding to the issue list.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for implementing the steps of the code inspection method as described in any one of claims 1 to 9 when executing the computer program.

Images