Code review method and device, equipment, storage medium and program product

Abstract

The application discloses a code review method and device, equipment, a storage medium and a program product. The method comprises the following steps: obtaining a first code, wherein the first code comprises target code and context information of the target code in a target range; extending the context information of the target code in the target range to complete function information where the target code is located to obtain second code; selecting a target rule set matched with the technical scene and code execution logic of the second code from an original rule set; and performing review on the second code based on the target rule set through a large language model to obtain a review result. According to the code review method, the accuracy of code review can be improved.

Description

Technical Field

[0001] This application belongs to the field of code review technology, and in particular relates to a code review method, apparatus, device, storage medium and program product. Background Technology

[0002] With the rapid development of large language models, their application in code review has attracted increasing attention. Code review schemes based on large language models can achieve flexible code inspection based on natural language rules, freeing them from the dependence on rule plugin development in traditional static analysis tools, and have good prospects for technological development.

[0003] However, the input context length (i.e., the number of tokens) of large language models has an inherent upper limit. When the number of review rules is large, it is impossible to input all review rules into the large language model at once, otherwise it will exceed the token capacity limit of the large language model, leading to review failure. Related technologies to solve this problem usually adopt limiting the number of input rules or processing the code in blocks. However, the former results in a large number of rules not being loaded, causing a significant lack of inspection coverage and affecting the accuracy of code review. The latter destroys the integrity of the code context, leading to a significant decrease in the accuracy of code review.

[0004] Therefore, there is an urgent need for a code review method based on a large language model to improve the accuracy of code review. Summary of the Invention

[0005] This application provides a code review method, apparatus, electronic device, computer-readable storage medium, and computer program product, which can improve the accuracy of code review.

[0006] In a first aspect, embodiments of this application provide a code review method, the method comprising: Obtain the first code, which includes the target code and its context information within the target scope; The target code is extended from the context information of the target scope to the complete function information where the target code is located to obtain the second code; Filter the target rule set from the original rule set that matches the technical scenario and code execution logic of the second code; The second code is reviewed using a large language model based on the target rule set, and the review results are obtained.

[0007] Secondly, embodiments of this application provide a code review apparatus, the apparatus comprising: An acquisition module is used to acquire first code, the first code including target code and its context information within the target scope; An extension module is used to extend the context information of the target code within the target scope to the complete function information where the target code is located, to obtain a second code; The filtering module is used to filter target rule sets from the original rule set that match both the technical scenario and the code execution logic of the second code; The review module is used to review the second code based on the target rule set using a large language model, and obtain the review results.

[0008] Thirdly, embodiments of this application provide an electronic device, which includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements any of the possible implementations of the first aspect described above.

[0009] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the method in any of the possible implementations of the first aspect described above.

[0010] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform a method as described in any of the possible implementations of the first aspect above.

[0011] In this application embodiment, on the one hand, by extending the context information of the target code within the target scope to the complete function information where the target code resides, a second code is obtained. Furthermore, by reviewing the second code using a large language model, sufficient function-level context can be provided during code review using the large language model, thereby improving the accuracy of code review. On the other hand, through a two-stage review mechanism—first filtering a target rule set from the original rule set that matches both the technical scenario and code execution logic of the second code, and then reviewing the second code based on the target rule set—irrelevant rules can be quickly filtered out, reducing the number of rules. Then, precise review is performed based on the target rule set, thereby improving the coverage and accuracy of rule checks and ultimately enhancing the accuracy of code review. Thus, through this application embodiment, the accuracy of code review can be improved. Attached Figure Description

[0012] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1This is a flowchart illustrating a code review method provided in one embodiment of this application; Figure 2 This is a flowchart illustrating a code review method provided in another embodiment of this application; Figure 3 This is a schematic diagram of a code review system provided in one embodiment of this application; Figure 4 This is a schematic diagram of the structure of a code review device provided in one embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Detailed Implementation

[0014] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0015] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0016] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0017] Furthermore, the acquisition, storage, use, and processing of data in this application's technical solution all comply with relevant national laws and regulations.

[0018] To address the related technical issues, embodiments of this application provide a code review method, apparatus, electronic device, computer-readable storage medium, and computer program product.

[0019] The code review method provided in the embodiments of this application is described below.

[0020] Figure 1 A flowchart illustrating a code review method according to an embodiment of this application is shown. This code review method can be executed by a code review system. Figure 1 As shown, the code review method provided in this application includes the following steps: S110. Obtain the first code, which includes the target code and its context information within the target scope; S120. Extend the context information of the target code within the target scope to the complete function information where the target code is located to obtain the second code; S130. Select a target rule set from the original rule set that matches the technical scenario and code execution logic of the second code; S140. The second code is reviewed using a large language model based on the target rule set, and the review results are obtained.

[0021] In this application embodiment, on the one hand, by extending the context information of the target code within the target scope to the complete function information where the target code resides, a second code is obtained. Furthermore, by reviewing the second code using a large language model, sufficient function-level context can be provided during code review using the large language model, thereby improving the accuracy of code review. On the other hand, through a two-stage review mechanism—first filtering a target rule set from the original rule set that matches both the technical scenario and code execution logic of the second code, and then reviewing the second code based on the target rule set—irrelevant rules can be quickly filtered out, reducing the number of rules. Then, precise review is performed based on the target rule set, thereby improving the coverage and accuracy of rule checks and ultimately enhancing the accuracy of code review. Thus, through this application embodiment, the accuracy of code review can be improved.

[0022] The specific implementation methods for each of the above steps are described below.

[0023] In some embodiments, in S110, the target code can be modified code or any other code that needs to be reviewed, without limitation. Modified code refers to code that changes relative to the base code (i.e., the previous version of code released before the start of this iteration) during code version iteration. This change includes at least one of adding, modifying, and deleting code. Furthermore, the target range is a pre-defined code interval, typically extending a fixed number of lines upwards and downwards from the line containing the target code. The context information is all the code within this code interval. For example, if the target code is on line 10 of a file, and the pre-defined target range is 3 lines above and below, then all the code from line 7 to line 13 constitutes the context information. That is, this part of the code includes both the target code itself and the surrounding reference code.

[0024] In some embodiments, during S120, when performing code reviews based on a large language model, especially for scenarios involving changes to cloud-native parameters and modifications within complex functions, the fixed number of lines of context information is often insufficient to provide the large language model with adequate function-level context. This can lead to a decrease in the accuracy of code reviews due to insufficient context. Complex functions typically refer to functions with many lines of code, deeply nested branching logic, and multiple layers of loops or conditional statements, making their overall structure and execution flow difficult to understand quickly.

[0025] Therefore, in order to improve the accuracy of code review, the context information of the target code within the target scope can be extended to the complete function information of the target code. That is, the granularity of context information extraction is enlarged from the line number range to the function level, and the complete function to which the target code belongs is used as the boundary of the context information, thereby changing the first code into the second code.

[0026] As an example, a code review system may include a diff intelligent scaling module. This module can be used to expand the target code's context information within the target scope to include the complete function information of the target code, while preserving the target code's context information within that scope for subsequent code repair and verification.

[0027] Therefore, in order to improve the accuracy of code review while also considering its efficiency, in some embodiments, the above-mentioned S120 may specifically include: parsing the application scenario of the target code; and, in cases where the application scenario involves changes to cloud-native parameters and / or modifications within complex functions, expanding the context information of the target code within the target scope to include the complete function information containing the target code. Thus, by scaling the code context for specific scenarios such as changes to cloud-native parameters and modifications within complex functions, it is possible to improve the accuracy of code review while also considering its efficiency.

[0028] In addition, to improve the accuracy of identifying complete function information and thus improve the accuracy of code review, in some embodiments, the above-mentioned S120 may specifically include: Parse the first code and generate an abstract syntax tree for the first code; Determine the target location of the target code within the abstract syntax tree; The complete function information to which the target location belongs in the abstract syntax tree is determined as the complete function information where the target code is located; Expanding the context information to complete function information yields the second code.

[0029] Here, an abstract syntax tree (AST) is a tree-like data structure obtained by parsing source code according to the syntax rules of a programming language. It precisely expresses the logical relationships and organizational hierarchy between various syntactic elements in the code (such as function declarations, variable definitions, conditional statements, loop structures, etc.) using a hierarchical tree structure. Unlike raw text code, an AST abstractly preserves the logical structure of the code while filtering out formatting information such as spaces, newlines, indentation, and comments that have no impact on the semantics of the program. This allows the syntactic structure of the code to be traversed, queried, and analyzed programmatically.

[0030] In this embodiment, the core function of the abstract syntax tree is to transform the first code from a linear text form into a structured data form, thereby supporting the precise location of the target code in the tree structure and further tracing the complete function boundary to which it belongs.

[0031] This application embodiment first generates an abstract syntax tree of the first code, and then identifies the complete function information of the target code based on the abstract syntax tree. This can improve the accuracy of identifying complete function information, and thus improve the accuracy of code review.

[0032] In some embodiments, in S130, the original rule set includes multiple natural language rules (hereinafter referred to as rules) organized and entered according to coding rules or security specifications. Each rule may include fields such as applicable programming language, applicable scenario, title, content, rule type, and rule risk level. The applicable programming language is the programming language to which the rule applies, such as Java, C, Python, etc. Applicable scenarios include data querying, microservices, cloud-native environments, and Remote Procedure Call (RPC) calls. The title describes the general category of the rule. The content is the specific content of the rule, describing the specific inspection points and providing examples. Rule types include coding specifications and security specifications. Rule risk levels include high, medium, and low levels.

[0033] The following is an example of a Java coding style rule (N+1 query style rule): Applicable programming language: Java Applicable scenarios: data query, microservices Title: Guidelines for Avoiding N+1 Queries content: 2.3.8.4 Prevention of N+1 Query Problem Terminology Explanation: The N+1 query problem refers to an inefficient querying scenario where a main query is executed to retrieve N master data records, followed by a join query for each master data record to retrieve related data, ultimately resulting in 1+N query statements. This significantly increases the number of database interactions and degrades system performance, especially with large datasets. This rule applies to Java data querying scenarios based on Object-Relational Mapping (ORM) frameworks. Examples of ORM frameworks include MyBatis and JPA (Java Persistence API).

[0034] 2.3.8.4.1 Prohibited Scenarios Do not perform join queries within loops to avoid triggering N+1 queries. It is strictly forbidden to iterate through the master data list and perform join queries on each record to obtain join information. This approach will cause the number of database queries to increase linearly with the amount of master data, severely impacting system response speed.

[0035] 2.3.8.4.2 Recommended Implementation Method By employing join queries or batch queries, N+1 queries can be optimized into a single query, reducing the number of database interactions and improving query efficiency. Specifically, this can be achieved through the join query function and batch query application programming interface (API) of the ORM framework, ensuring that master data and related data are queried in a single operation.

[0036] 2.3.8.4.3 Examples of Positive and Negative Cases Counterexample (exists an N+1 query problem): Java / / 1. Execute one main query to retrieve a list of all users (first query) List <user>userList = userMapper.selectAllUsers(); / / 2. Loop through the user list and perform a relational query on each user to retrieve order information (N queries, where N is the number of users) for (User user : userList) { / / Each loop triggers one database query, resulting in N+1 queries. List <order>orderList = orderMapper.selectByUserId(user.getId()); user.setOrderList(orderList); } Positive example (optimizing the N+1 query problem): Java / / Method 1: Use a join query to retrieve all user and related order information in a single query (only one query required). List <user>userList = userMapper.selectAllUsersWithOrders(); / / Method 2: Use batch query, first query the master data, then batch query the related data (a total of 2 queries, regardless of N) List <user>userList = userMapper.selectAllUsers(); / / First query / / Extract all user IDs and batch query related orders (second query) List <long>userIds = userList.stream().map(User::getId).collect(Collectors.toList()); List <order>orderList = orderMapper.selectByUserIds(userIds); / / Manually join data to avoid loop queries Map <Long, List <order>> orderMap = orderList.stream() .collect(Collectors.groupingBy(Order::getUserId)); userList.forEach(user -> user.setOrderList(orderMap.getOrDefault(user.getId(), Collections.emptyList()))); 2.3.8.4.4 Inspection Points 1. Check all loop bodies (for, foreach, etc.) to confirm whether there are any database join operations; 2. Check the ORM framework query statements to confirm whether loop queries have been replaced by join queries or batch queries; 3. For query scenarios with large amounts of data, performance testing is required to verify query efficiency and avoid implicit N+1 query problems.

[0037] As an example, a code review system may include a natural language rule management module. This module maintains natural language rules for coding standards and security specifications. Each coding standard and security specification may correspond to a separate initial rule set.

[0038] Furthermore, the original rule set can contain all natural language rules used for code review. Therefore, the target rule set can be selected from the original rule set based on the programming language, technical scenario, and code of the second code.

[0039] In some embodiments, the above-mentioned S130 may specifically include: Obtain the original rule set, which includes multiple rules. Each rule includes the content to be checked and the applicable scenarios. Analyze the second code to determine its technical context and execution logic; Based on the matching relationship between the technical scenario and the applicable scenario, and the matching relationship between the code execution logic and the rule inspection content, multiple target rules related to the technical scenario of the second code are determined from multiple rules; Based on multiple target rules, a target rule set is determined.

[0040] Here, the content of rule checks can be determined based on at least one of the rule's title and content. The applicable scenario can be determined based on at least one of the rule's applicable scenario, title, and content. Furthermore, the specific process of parsing the second code, determining its technical scenario and execution logic, and identifying multiple target rules related to the technical scenario of the second code from among multiple rules based on the matching relationship between the technical scenario and the applicable scenario, and the matching relationship between the code execution logic and the rule check content, and finally determining the target rule set, can be completed by a large language model or by a programmatic rule filtering module (such as a rule filtering engine); this is not limited here.

[0041] As an example, a code review system can include a code review module and a large model adaptation module. The code review module reviews code according to natural language rules and records information such as identified issues, rule violations, and the corresponding original code. Specifically, the code review module performs initial rule screening and precise review. First, it screens the original rule set involved in the code, and then reviews the target rule set after the initial screening. This avoids the token limitations of large models, using fewer rules for precise code review and improving the accuracy of code review. On the other hand, the large model adaptation module provides a unified interface for the inference interface of large language models, supporting multiple mainstream large language models. It completes the assembly of prompt words, model invocation, result parsing, and exception handling, shielding the differences between different large model interfaces, ensuring the system's universality and scalability, and providing unified support for all aspects that rely on large language models, such as natural language rule parsing, initial rule screening, precise review, and automated repair.

[0042] If rule screening is performed based on a large language model, the prompt words for rule screening can be as follows: # Initial keyword filtering (rule-based filtering + scenario adaptation) ## Role Definition Role: Professional code review expert, proficient in {{type}}, skilled in code scenario identification and rule matching.

[0043] Background: The {{type}} code needs to be initially screened for rules. Combined with the intelligently expanded and shrunk diff context, relevant rules are selected and matched with scenario-specific rules to reduce the amount of input for subsequent accurate review.

[0044] Profile: Possesses extensive experience with {{type}} coding standards, can quickly identify code technology scenarios (microservices, cloud-native, database operations, etc.), accurately matches corresponding rules, and leaves no essential checks out.

[0045] ## Core Competency Requirements Skills: 1. Quickly parse the current diff context to identify code execution logic and technical scenarios; 2. Based on code execution logic and technical scenarios, accurately match rules and code, and filter irrelevant rules; 3. Automatically load scenario-specific rules to ensure rule coverage; 4. Output only a list of rule identifiers (IDs) without adding any irrelevant content.

[0046] ## Work Goals and Constraints Goals: Filter out rule IDs related to the current diff context, load the corresponding scenario-specific rule IDs, and output a list of pure IDs (mandatory check items must be included).

[0047] Constraints: 1. Output retains only the rule ID, without any explanation, comments, or extra characters; 2. Strictly matches the code scenario, and does not load rules related to irrelevant scenarios; 3. Does not omit any rules related to the code content.

[0048] ## Input Information - Checkpoint (Rule ID + Title): {{compile_rules_title_list}} - Smartly scaled diff context: {{processed_diff_context}} - Current programming language: {{type}} ## Output Format Output only a list of rule IDs, one ID per line, with no other content.

[0049] Here, `type` represents the programming language type corresponding to the source code. `compile_rules_title_list` is the original rule set, including a list of all encoded rules, which must include at least a rule ID and a title. The large language model can query the original rule set from the rule base based on the rule ID and title to obtain the applicable scenarios and content of the rules. Of course, the large language model can also determine the rule's inspection content and applicable scenarios by parsing the rule title, which is not limited here. In addition, `processed_diff_context` is the code context processed by the diff intelligent scaling module, including either the second or third code.

[0050] This application embodiment, by performing preliminary rule screening before conducting precise review, can quickly filter out irrelevant rules, reduce the number of rules, and reduce interference from irrelevant information. This enables code review based on a large language model to support more effective rules (such as checking more than 500 rules at the same time), and alleviates the token restriction of prompt words on the large language model. As a result, it can improve the coverage and accuracy of rule checks during precise review, and improve the efficiency and accuracy of code review.

[0051] Furthermore, if the amount of code to be reviewed exceeds the preset amount, the code review scenario can be identified as an ultra-large code review scenario. In ultra-large code review scenarios, due to the large number of files, and the fact that these files often contain a large amount of irrelevant text (such as non-core business content like SQL insertion data), the overall volume of the diff context is very likely to exceed the token capacity limit of the large language model, thus preventing the review process from being triggered normally. At the same time, the inclusion of a large amount of irrelevant content will also interfere with the semantic judgment of the large language model, further reducing review efficiency and accuracy. Currently, there is a lack of targeted context optimization solutions, making it difficult to adapt to the actual needs of ultra-large code reviews.

[0052] Therefore, in order to improve the efficiency and accuracy of code review, in some embodiments, the above-mentioned S130 may specifically include: If the amount of code corresponding to the second code exceeds the preset amount of code, the first file and the second file are determined from multiple files, and the code in the first file is more important than the code in the second file; The second file is compressed to obtain the third file; The code in the first file and the third file is designated as the third code; Select target rule sets from the original rule set that match the technical scenario and code execution logic of the second code.

[0053] Here, the second code corresponds to multiple files, meaning it exists in multiple files. These multiple files include the first file and the second file. The amount of code corresponding to the second code exceeding a preset limit can include the number of modified files exceeding a preset limit (e.g., 5). If the amount of code corresponding to the second code exceeds the preset limit, this review scenario can be identified as a very large code review scenario. Therefore, the first file and the second file to be compressed can be identified among the multiple files to reduce the amount of code to be reviewed. The code in the first file is considered more important than the code in the second file. The first file can be, for example, a file containing code related to core business processes. These core business processes are the most important and fundamental business processing links in the system (e.g., order creation, payment settlement, user authentication, etc., which run through the main system thread). Their corresponding code files typically include core service interfaces, business logic implementation classes, and control layer code files that bear the main business responsibilities. The second file can be, for example, a file containing code related to non-core auxiliary business processes. Non-core auxiliary business processes refer to peripheral functions or auxiliary support business processing links of the system, which have limited impact on the continuity of the main business of the system. The second file can be, for example, text content such as documentation in the code repository, configuration file comments, etc., that have no impact on the program's running logic, as well as structured query language (SQL) data insertion scripts used for test data initialization or data migration.

[0054] Thus, embodiments of this application can determine a first file and a second file among multiple files based on the business process attributes corresponding to the files. The business process attributes include core business processes and non-core auxiliary business processes. Specifically, if the business process attribute corresponding to a file is a core business process, then that file can be determined as the first file; if the business process attribute corresponding to a file is a non-core auxiliary business process, then that file can be determined as the second file. The business process attribute corresponding to a file can be determined based on the filename and file extension. For example, if the filename is Service.java, Controller.java, or the file extension is .java and the package path contains core / service / controller, then the business process attribute corresponding to the file is a core business process; if the filename is Util.java, Config.java, or the file extension is .xml, .sql, .md, .xlsx, .pdf, etc., then the business process attribute corresponding to the file is a non-core auxiliary business process. In addition, if the target code is modified code, the business process attributes corresponding to the file can also be determined based on the code change comments. For example, if the comments contain keywords such as feat or core, it is classified as a core process, and if they contain keywords such as test, doc, or config, it is classified as a non-core auxiliary business process.

[0055] Based on this, in order to improve the accuracy of determining the first and second files, in some embodiments, when the target code is modified code, the first and second files are determined from multiple files, which may specifically include: Obtain the performance scores of multiple files under multiple evaluation metrics, which include at least one of the following: the business process attributes corresponding to the file, the amount of code changes, and the file size. For each file, the target score of the file is obtained by weighting the scores of multiple indicators based on the weights corresponding to the scores of multiple indicators. Based on multiple target scores, the first and second files are determined from multiple files.

[0056] The description of business process attributes is provided above and will not be repeated here. Additionally, code change volume can refer to the amount of code corresponding to the changed code portion (excluding context information), and file size can refer to the file size corresponding to the changed code and its complete function information (including context information). Multiple evaluation metrics are sorted in descending order of weight, resulting in the following ranking: business process attributes, code change volume, and file size. That is, business process attributes have the highest weight, followed by code change volume, and then file size.

[0057] Furthermore, different evaluation metrics can correspond to different scoring rules. For example, regarding business process attributes, the metric scores for core business processes and non-core auxiliary business processes differ. The metric score for core business processes can be higher than that for non-core auxiliary business processes. Regarding code change volume, the amount of code change can be positively correlated with the metric score; that is, the greater the amount of code change, the higher the metric score. Regarding file size, if the file size is less than a preset threshold, the file size can be positively correlated with the metric score. However, if the file size is greater than the preset threshold, the file size and metric score are negatively correlated. This is because once the preset threshold is exceeded, an excessively large file often means that the file bears too many responsibilities, and readability and maintainability deteriorate.

[0058] Based on the different scoring rules corresponding to different evaluation indicators, the indicator scores of multiple files under multiple evaluation indicators can be determined. Then, for each file, the scores of multiple indicators are weighted and calculated to obtain the target score of the file. Generally, if the target score is higher than the scoring threshold, the file can be identified as the first file. If the target score is less than or equal to the scoring threshold, the file can be identified as the second file.

[0059] The embodiments of this application improve the accuracy of determining the first and second documents by using multiple evaluation indicators to jointly determine the first and second documents.

[0060] Subsequently, by compressing the second file, a smaller third file can be obtained. Compression can include at least one of the following: abstract extraction, keyword extraction, and format conversion.

[0061] If the target code is modified code, then the second file is compressed to obtain a third file, which may specifically include: Extract the change code from the second file to obtain the change summary; Based on the change summary, the third document is determined.

[0062] Here, by semantically summarizing all the changes in the second file and retaining only the core information of the changes, such as the file types involved, the main objects of operation, the number of changes, and the brief purpose, and summarizing it into a summary text in the form of natural language description, we can obtain the change summary.

[0063] Thus, through the compression method described above, the originally large second file (e.g., a script file containing hundreds of SQL insert statements) can be compressed into a third file containing only a summary of core changes (e.g., adding 3 SQL insert statements involving basic user table data). The compression rate can reach over 90%, effectively avoiding the problem of exceeding the capacity limit of the large language model token due to the overall size of the diff context being too large. This allows this application to support ultra-large code reviews containing more than 50 modified files, while reducing the interference of irrelevant content on the judgment of the large model, and improving the review efficiency and accuracy in ultra-large code review scenarios.

[0064] In addition, to improve the robustness of code review, in some embodiments, the above-mentioned determination of the first file and the second file among multiple files based on multiple target scores may specifically include: Candidate files are selected sequentially from multiple files according to the target score from low to high, until the sum of the code size of the remaining files and the estimated compressed code size of the candidate files is less than or equal to the preset code size. The remaining files are the files other than the candidate files in the multiple files. The candidate file is designated as the second file, and the remaining file is designated as the first file.

[0065] As described above, the target score is positively correlated with the importance of the code in the file. In this embodiment, for each candidate file with a lower score, the estimated compressed code size corresponding to that candidate file can be obtained. This estimated compressed code size can be determined based on the estimated compression ratios corresponding to different candidate files. For example, if the candidate file is an SQL script, the estimated compression ratio can be 90%, and the estimated compressed code size can be determined based on the product of the current code size of the candidate file and its corresponding estimated compression ratio.

[0066] Then, it is determined whether the sum of the code size of the remaining file and the estimated compressed code size of the candidate file is less than or equal to the preset code size. If so, the candidate file is determined as the second file and the remaining file is determined as the first file. If not, the candidate file is selected from multiple files in order of target score from low to high, until the sum of the code size of the remaining file and the estimated compressed code size of the candidate file is less than or equal to the preset code size.

[0067] This application embodiment dynamically evaluates the amount of code and compresses different types of files as needed. This ensures that the review process can be executed normally while preserving the complete context of high-priority core files as much as possible. It achieves the optimal balance between review accuracy and token capacity constraints, while avoiding unnecessary information loss in non-ultra-large scenarios and improving the robustness of code review.

[0068] In some embodiments, in S140, after determining the target rule set and the second code, precise review prompts can be determined based on the target rule set and the second code. These precise review prompts are then input into a large language model to perform precise review of the second code based on the target rule set, yielding a review result. The review result includes the location of the problematic code, the corresponding rule, and modification suggestions. The precise review prompts may be as follows: # Precise review prompts (review each rule individually) ## Role Definition Role: Senior Software Engineer, Professional Code Reviewer.

[0069] Background: Based on specified encoding / security standards, the intelligently scaled diff context needs to be accurately reviewed to identify violations and output standardized results, providing a basis for subsequent automated remediation.

[0070] Profile: Proficient in {{type}} syntax features, coding standards and security requirements; able to accurately locate code violations, provide feasible modification suggestions, and strictly adhere to output format requirements.

[0071] ## Core Competency Requirements Skills: 1. Deeply analyze the diff context and identify violations based on specified rules; 2. Accurately label problematic line numbers and clarify the content of the violation; 3. Provide specific and actionable modification suggestions; 4. Classify the severity of problems by level and output standardized JSON.

[0072] ## Work Goals and Constraints Goals: Based on the current rules, conduct a comprehensive review of the diff context and output a structured JSON containing the issue line number, the violation content, suggested modifications, and the severity level.

[0073] Constraints: 1. Reviews are strictly based on the provided rules, with no additional review criteria added; 2. No code modifications are made, only issues are identified and suggestions are provided; 3. Output is limited to JSON, without any explanations, comments, or Markdown formatting.

[0074] ## Input Information - The intelligently scaled diff context (with line numbers): {{processed_diff_context}} - Rules to be reviewed: {{rule}} - Current programming language: {{type}} ## Output Format (Strictly Follow) [{ "index": integer (the line number of the problem), "compile_rule": "string (the specific rule being violated)", "proposal": "String (specific, feasible modification suggestions)", "grade": Integer (1 = low risk, 2 = medium risk, 3 = high risk) ## Supplementary Explanation - If no violations are found, leave all fields blank and maintain the above JSON list format; - Grade grading standards: 3 (high) = violation of regulations and serious safety risks; 2 (medium) = violation of regulations and potential safety hazards; 1 (low) = minor violation of regulations and no safety risks.

[0075] Here, `type` represents the source code language type. `rule` is a single encoding rule after initial screening, including its title and content. `processed_diff_context` is the code context after processing by the diff intelligent processing module. The implementation of security specifications is similar and will not be elaborated upon here.

[0076] Based on this, in order to simplify the problem-solving process and improve code development efficiency, in some embodiments, this application also provides another implementation of the code review method, as detailed in the following embodiments.

[0077] Please see Figure 2 The code review method provided in this application embodiment may further include the following steps after S160 shown in the above embodiment: S210. Based on the location of the problematic code and the context information of the problematic code within the target scope, determine the problematic code fragment; S220. Using a large language model, based on the rules and modification suggestions corresponding to the problematic code, repair the problematic code fragment to obtain the repaired code fragment, and generate the repair logic. S230, Output the problematic code snippet, the repair code snippet, the repair logic, the rules corresponding to the problematic code, and modification suggestions.

[0078] Here, the code review system can include an automatic repair module. This module can generate code to fix identified issues using a large language model, including problematic code snippets, repairable code snippets, repair logic, corresponding rules, and suggested modifications.

[0079] The prompts used to generate code to fix the reviewed issues can be as follows: # Automated repair prompts (precise replacement + business conservation) ## Role Definition Role: Senior code fix engineer, specializing in code style fixing and business logic conservation.

[0080] Background: Based on the review issues, the code needs to be fixed within the original target scope, while fully preserving the original business logic, generating code snippets that can be directly and safely replaced, and adapting to the automated replacement process.

[0081] Profile: Proficient in {{type}} coding standards, able to accurately match review issues with code snippets, strictly control the scope of fixes, and ensure that the functionality of the fixed code is completely consistent with the original code.

[0082] ## Core Competency Requirements Skills: 1. Accurately understand review issues and locate the code snippets to be fixed; 2. Modify only within the target scope, without touching any code outside the target code; 3. Strictly follow coding standards in the fix, without changing the business logic; 4. Generate code that can be directly and safely replaced, with clear annotations.

[0083] ## Work Goals and Constraints Goals: For review issues, generate fix code that conforms to specifications, retains business logic, and is only within the target scope, outputting standardized JSON (including issues, old code, and new code) for safe replacement.

[0084] Constraints: 1. No business logic or functional implementation shall be modified; 2. All modifications shall be strictly limited to the target scope, and those exceeding the scope shall be considered invalid; 3. The repaired code shall be directly runnable and functionally consistent with the original code; 4. The output shall only retain JSON, without any explanation, comments or extra content.

[0085] ## Input Information - The intelligently scaled diff context (with line numbers): {{processed_diff_context}} - Original diff change range (i.e., target range): {{original_diff_range}} - Issues identified during the review: {{review_issues}} - Current programming language: {{type}} ## Output Format (Strictly follow, adapt for safe replacement) { "problem": "string (clearly corresponds to the violation issue identified during the review, consistent with the review result)", "oldCode": "String (the original code snippet to be fixed, i.e. the problematic code snippet, marked with line numbers, format: line number: original code, multiple lines separated by newlines)", "newCode": "String (the repaired code snippet, corresponding one-to-one with the line numbers of oldCode, format: line number: repaired code, multiple lines separated by newlines)", "repairNote": "String (1-2 sentences explaining the repair logic, clarifying the key modifications, and facilitating replacement and verification"} ## Supplementary Requirements 1. The line numbers in oldCode and newCode strictly correspond; only the non-compliant parts have been modified to ensure that it can be directly copied and replaced. 2. The repairNote should be concise and clear, clearly stating the modification logic (e.g., "Fixed the issue of not adding a default branch to the switch statement, conforming to coding standards"). 3. Fixed the issue where additional comments were no longer needed at the beginning of the code; related explanations have been integrated into the repairNote field.

[0086] Here, `type` indicates the source code language type. `review_issues` is a list of coding rule issues, including titles and content. See the results below: json {"index": 12, "compile_rule": "Violated rule content", "proposal": "Specific suggestions for modification", "grade": 1} The repair prompts for security specifications are similar, so they will not be repeated here.

[0087] In addition to the above, other steps of the method in the embodiments of this application can be found in the above text. Figure 1 The relevant descriptions of the embodiments shown will not be repeated here.

[0088] This application embodiment uses the above-described closed-loop automated problem-solving process to directly generate repair code that does not affect business logic, simplifying the problem-solving work and improving code development efficiency.

[0089] Therefore, in order to improve the security of code repair, in some embodiments, after S230 above, the method may further include: If the user approves the repair code snippet based on the problematic code snippet, the repair logic, the rules corresponding to the problematic code, and the modification suggestions, the repair code snippet will be tested for its scope of repair, and the test results will be obtained. If the detection results indicate that the repair code snippet is within its target range, execute the application operation of the repair code snippet. If the detection results indicate that the repair code snippet exceeds its target scope, the application operation of the repair code snippet will be intercepted.

[0090] Here, after the repair code snippet is generated, users can confirm the repair code snippet based on the problematic code snippet, the repair logic, the rules corresponding to the problematic code, and modification suggestions.

[0091] As an example, the auto-repair module can be integrated with a Git code management tool. If the user approves, the auto-repair module with integrated Git code management can generate a patch corresponding to the code snippet being repaired, and perform a scope check on the repaired code snippet, obtaining the check result. If the check result indicates that the repaired code snippet is within its target scope, the application operation for that code snippet can be executed to complete the code repair. If the check result indicates that the repaired code snippet is outside its target scope, the application operation for that code snippet can be intercepted, and the user will be prompted to confirm whether to re-enter the review process.

[0092] This application embodiment improves code repair security by performing a safety check on the scope of changes during patch application and blocking dangerous patches that exceed the scope of changes.

[0093] To better describe the overall solution, some specific examples are given based on the above embodiments.

[0094] For example, such as Figure 3 As shown, the code review system in this embodiment includes a natural language rule management module 31, a diff intelligent scaling module 32, a code review module 33, an automatic repair module 34, and a large model adaptation module 35. The natural language rule management module 31, located in the user interface (UI) layer, is used to maintain natural language rules for coding standards and security standards. Each coding standard and security standard can correspond to an original rule set. Furthermore, the UI layer may also include a code merging module 36. Users can initiate code merging requests in the code merging module 36. This code merging request includes first code, which includes modified code and its context information within the target scope. The code merging request can be used to request a review of the first code, and if the review is successful, to submit the first code to the code repository to merge it into the complete code.

[0095] Additionally, the large model adaptation module 35 can be located in the model adaptation layer. This layer integrates the large language model 37. The large model adaptation module 35 can be used to uniformly interface with the inference interface of the large language model 37, supporting multiple mainstream large language models. It completes the assembly of prompt words, model invocation, result parsing, and anomaly handling, shielding the differences between various large model interfaces, ensuring the system's universality and scalability, and providing unified support for all aspects relying on the large language model, such as natural language rule parsing, rule initial screening, accurate review, and automated repair.

[0096] Additionally, the diff intelligent scaling module 32, code review module 33, and automatic repair module 34 can be located in the functional layer. The diff intelligent scaling module 32 can be used to perform diff intelligent scaling on the first code. Diff intelligent scaling includes expanding the context information of the changed code in the first code within the target scope to the complete function information where the changed code resides, resulting in the second code; and compressing the second code into a third code if the code size exceeds a preset limit. The code review module 33 can be used to interact with the large language model 37 to perform initial rule screening and precise review. First, it performs initial screening on the original rule set involved in the code (the second or third code), and then reviews the problem-solving aspects of the target rule set after initial screening to obtain the review results. This avoids the token limitations of the large model, uses fewer rules for precise code review, and improves the accuracy of code review. The original rule set can be derived from the natural language rule base 38, which can also be located in the functional layer.

[0097] The automatic repair module 34 can interact with the large language model 37. Based on the review results, it locates the problematic code snippets, repairs the problematic code snippets, obtains the repaired code snippets, and generates repair patches corresponding to the repaired code snippets. When the patches are applied, a safety check on the scope of changes is performed to intercept dangerous patches that exceed the scope of changes and prompts the user to re-trigger the code merge request review process, thereby achieving the effect of automatically repairing review issues.

[0098] In summary, the customization threshold for coding and security specifications in this application embodiment is low: by using natural language rule sets, the threshold for custom coding and security specification rules is lowered, allowing scanning rules to meet daily development needs more quickly, shortening the rule customization cycle from several weeks to minutes, and enabling non-technical personnel to participate in rule customization.

[0099] Furthermore, the closed-loop automated issue remediation process directly generates fix code that does not affect business logic, simplifying the remediation work and improving development efficiency. By integrating with the Git code management tool, after the user confirms the fix code, the patch is generated and submitted to the code repository via API, optimizing the issue remediation process, significantly reducing the manual cost of issue remediation, and improving the user experience.

[0100] In addition, the rule-based initial screening filters out non-relevant specifications to support more specifications, improving review efficiency and easing the token restrictions on prompt words in large models. It can check more than 500 rules at the same time.

[0101] In addition, the diff context intelligent compression technology significantly reduces the tokens occupied by irrelevant content, supporting ultra-large code reviews containing more than 50 modified files, avoiding the token limit problem, and greatly improving the review accuracy.

[0102] In addition, the two-stage process of initial screening and review reduces interference from irrelevant information, further improving the accuracy of the review; by intercepting modifications that exceed the scope when applying patches, the risk of accidental modifications during repair is effectively reduced, and the security of code repair is improved.

[0103] Furthermore, the code review method in this application is highly versatile and adaptable to existing R&D processes. It can seamlessly integrate with existing Git code management systems and continuous integration / continuous deployment (CI / CD) pipelines, and can be quickly implemented without large-scale modifications to existing R&D processes. It is suitable for code quality control scenarios in most enterprise-level R&D teams.

[0104] Based on the code review method provided in the above embodiments, this application also provides specific implementation methods of the code review apparatus. Please refer to the following embodiments.

[0105] like Figure 4 As shown, a code review apparatus 400 provided in one embodiment of this application includes the following modules: The acquisition module 410 is used to acquire the first code, which includes the target code and its context information within the target scope; Extension module 420 is used to extend the context information of the target code within the target scope to the complete function information where the target code is located, to obtain the second code; The filtering module 430 is used to filter target rule sets from the original rule set that match the technical scenario and code execution logic of the second code. The review module 440 is used to review the second code based on the target rule set using a large language model, and obtain the review results.

[0106] The code review device 400 described above is explained in detail below: In some embodiments, the extension module 420 may specifically include: The parsing submodule is used to parse the first code and generate an abstract syntax tree for the first code; The first determining submodule is used to determine the target location of the target code in the abstract syntax tree; The second determination submodule is used to determine the complete function information to which the target position in the abstract syntax tree belongs as the complete function information where the target code is located. An extended submodule is used to expand the context information to complete function information, resulting in a second code.

[0107] In some embodiments, the second code corresponds to multiple files. Based on this, the filtering module 430 may specifically include: The third determination submodule is used to determine the first file and the second file from multiple files when the amount of code corresponding to the second code exceeds the preset amount of code. The code in the first file is more important than the code in the second file. The compression submodule is used to compress the second file to obtain the third file; The fourth determination submodule is used to determine the code in the first file and the third file as the third code; The filtering submodule is used to filter target rule sets from the original rule set that match the technical scenarios and code execution logic of the third-party code.

[0108] In some embodiments, the target code is modified code, which is code that changes relative to the base code during code version iteration. Based on this, the compression submodule may specifically include: The extraction unit is used to extract a summary of the change code in the second file to obtain a change summary. The first determining unit is used to determine the third document based on the change summary.

[0109] In some embodiments, the target code is modified code. Based on this, the fourth determining submodule may specifically include: The first acquisition unit is used to acquire the indicator scores of multiple files under multiple evaluation indicators. The multiple evaluation indicators include at least one of the business process attributes, code change volume and file size of the file. The business process attributes include core business processes and non-core auxiliary business processes. The calculation unit is used to perform a weighted calculation on the scores of multiple indicators for each file, based on the weights corresponding to the scores of multiple indicators, to obtain the target score of the file. The second determining unit is used to determine the first file and the second file from multiple files based on multiple target scores.

[0110] In some embodiments, the target score is positively correlated with the importance of the code in the file. Based on this, the fourth determining unit is specifically used for: Candidate files are selected sequentially from multiple files according to the target score from low to high, until the sum of the code size of the remaining files and the estimated compressed code size of the candidate files is less than or equal to the preset code size. The remaining files are the files other than the candidate files in the multiple files. The candidate file is designated as the second file, and the remaining file is designated as the first file.

[0111] In some embodiments, the filtering submodule may specifically include: The second acquisition unit is used to acquire the original rule set, which includes multiple rules, and each rule includes the content to be checked and the applicable scenarios. The parsing unit is used to parse the second code and determine its technical context and execution logic. The third determining unit is used to determine multiple target rules related to the technical scenario of the second code from multiple rules based on the matching relationship between the technical scenario and the applicable scenario, as well as the matching relationship between the code execution logic and the rule inspection content; The fourth determining unit is used to determine the target rule set based on multiple target rules.

[0112] In some embodiments, the review results include the location of the problematic code, the rules corresponding to the problematic code, and modification suggestions. Based on this, the code review apparatus 400 may further include: The identification module is used to identify the problematic code fragment based on the location of the problematic code and the context information of the problematic code within the target scope after the review results are obtained; The first repair module is used to repair problematic code snippets based on the rules and modification suggestions corresponding to the problematic code using a large language model, thereby obtaining repaired code snippets and generating repair logic; The output module is used to output problematic code snippets, repair code snippets, repair logic, rules corresponding to the problematic code, and modification suggestions.

[0113] In some embodiments, the code review apparatus 400 may further include: The detection module is used to perform a repair range detection on the repair code snippet after outputting the problematic code snippet, the repair code snippet, the repair logic, the rules and modification suggestions corresponding to the problematic code, and the user confirms that the repair code snippet passes the repair logic and the rules and modification suggestions corresponding to the problematic code, and obtain the detection result. The second repair module is used to perform the application operation of the repair code fragment when the detection result indicates that the repair code fragment is within its target range; The intercept module is used to intercept the application operation of the repair code fragment when the detection result indicates that the repair code fragment exceeds its target scope.

[0114] In this application embodiment, on the one hand, by extending the context information of the target code within the target scope to the complete function information where the target code resides, a second code is obtained. Furthermore, by reviewing the second code using a large language model, sufficient function-level context can be provided during code review using the large language model, thereby improving the accuracy of code review. On the other hand, through a two-stage review mechanism—first filtering a target rule set from the original rule set that matches the technical scenario and code execution logic of the second code, and then reviewing the second code based on the target rule set—irrelevant rules can be quickly filtered out, reducing the number of rules. Then, precise review is performed based on the target rule set, thereby improving the coverage and accuracy of rule checks and ultimately enhancing the accuracy of code review. Thus, through this application embodiment, the accuracy of code review can be improved.

[0115] Based on the code review method provided in the above embodiments, this application also provides specific implementation methods for electronic devices. Figure 5 A schematic diagram of the structure of an electronic device provided in one embodiment of this application is shown.

[0116] like Figure 5 As shown, the electronic device 500 may include a processor 510 and a memory 520 storing computer program instructions.

[0117] Specifically, the processor 510 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0118] Memory 520 may include mass storage for data or instructions. For example, and not limitingly, memory 520 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 520 may include removable or non-removable (or fixed) media. Where appropriate, memory 520 may be internal or external to electronic device 500. In a particular embodiment, memory 520 is a non-volatile solid-state memory.

[0119] In specific embodiments, the memory 520 may be implemented as a read-only memory (ROM), random access memory (RAM), static storage device, dynamic storage device, etc. The memory 520 may store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 520 and executed by the processor 510. The processor 510 implements any of the code review methods in the above embodiments by reading and executing the computer program instructions stored in the memory 520.

[0120] The processor 510 implements any of the code review methods described in the above embodiments by reading and executing computer program instructions stored in the memory 520.

[0121] In one example, electronic device 500 may also include communication interface 530 and bus 540. Wherein, as... Figure 5 As shown, the processor 510, memory 520, and communication interface 530 are connected through bus 540 and complete communication with each other.

[0122] The communication interface 530 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0123] Bus 540 includes hardware, software, or both, that couples components of an electronic device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-E) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses, or a combination of two or more of these. Where appropriate, bus 540 may include one or more buses. Although specific buses are described and illustrated in the embodiments of this application, this application considers any suitable bus or interconnection.

[0124] For example, the electronic device 500 can be a mobile phone, tablet computer, laptop computer, handheld computer, in-vehicle electronic device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc.

[0125] The electronic device can execute the code review method in the embodiments of this application, thereby achieving the combination Figures 1 to 2 The code review method described, and the beneficial effects of the corresponding method implementation, will not be elaborated here.

[0126] Furthermore, in conjunction with the code review methods in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the code review methods in the above embodiments. Examples of such computer-readable storage media include non-transitory computer-readable storage media, such as read-only memory (ROM).

[0127] The computer program instructions stored in the storage medium of the above embodiments are used to cause the computer to execute the code review method as shown in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0128] Based on the code review methods described in the above embodiments, this application provides a computer program product for implementation. When the instructions in this computer program product are executed by the processor of an electronic device, they implement any of the code review methods described in the above embodiments.

[0129] The computer program products of the above embodiments are used to implement the code review method shown in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0130] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0131] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0132] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0133] The aspects of this application have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by dedicated hardware performing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0134] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.< / order> < / order> < / long> < / user> < / user> < / order> < / user>

Claims

1. A code review method, characterized in that, include: Obtain the first code, which includes the target code and its context information within the target scope; The target code is extended from the context information of the target scope to the complete function information where the target code is located to obtain the second code; Filter the target rule set from the original rule set that matches the technical scenario and code execution logic of the second code; The second code is reviewed using a large language model based on the target rule set to obtain the review results.

2. The method according to claim 1, characterized in that, The step of extending the context information of the target code within the target scope to the complete function information where the target code resides to obtain the second code includes: Parse the first code to generate an abstract syntax tree for the first code; Determine the target location of the target code within the abstract syntax tree; The complete function information to which the target position belongs in the abstract syntax tree is determined as the complete function information where the target code is located; The context information is extended to the complete function information to obtain the second code.

3. The method according to claim 1, characterized in that, The second code corresponds to multiple files. The step of filtering a target rule set from the original rule set that matches both the technical scenario and the code execution logic of the second code includes: If the amount of code corresponding to the second code exceeds the preset amount of code, a first file and a second file are determined from the plurality of files, wherein the code in the first file is more important than the code in the second file; The second file is compressed to obtain the third file; The code in the first file and the third file is identified as the third code; Select a target rule set from the original rule set that matches both the technical scenario and the code execution logic of the third code.

4. The method according to claim 3, characterized in that, The target code is modified code, which is code that has changed relative to the base code during code version iteration. The third file, obtained by compressing the second file, includes: Extract the change code from the second file to obtain the change summary; Based on the change summary, the third document is determined.

5. The method according to claim 3, characterized in that, The target code is the modification code, and determining the first file and the second file among the plurality of files includes: Obtain the indicator scores of the multiple files under multiple evaluation indicators. The multiple evaluation indicators include at least one of the business process attributes, code change volume and file size of the file. The business process attributes include core business processes and non-core auxiliary business processes. For each file, the target score of the file is obtained by weighting the multiple indicator scores based on the weights corresponding to the multiple indicator scores respectively. Based on the multiple target scores, a first file and a second file are determined from the multiple files.

6. The method according to claim 5, characterized in that, The target score is positively correlated with the importance of the code in the file. Determining the first file and the second file from among the multiple files based on multiple target scores includes: Candidate files are selected sequentially from the multiple files according to the target score from low to high, until the sum of the code size of the remaining files and the estimated compressed code size of the candidate files is less than or equal to the preset code size. The remaining files are the files other than the candidate files in the multiple files. The candidate file is identified as the second file, and the remaining file is identified as the first file.

7. The method according to claim 1, characterized in that, The step of filtering a target rule set from the original rule set that matches both the technical scenario and the code execution logic of the second code includes: Obtain the original rule set, which includes multiple rules, each rule including rule inspection content and applicable scenarios; Analyze the second code to determine its technical context and execution logic; Based on the matching relationship between the technical scenario and the applicable scenario, and the matching relationship between the code execution logic and the rule inspection content, multiple target rules related to the technical scenario of the second code are determined from the multiple rules; Based on the multiple target rules, the target rule set is determined.

8. The method according to any one of claims 1-7, characterized in that, The review results include the location of the problematic code, the corresponding rules for the problematic code, and modification suggestions; After obtaining the review results, the method further includes: Based on the location of the problematic code and the contextual information of the problematic code within the target range, the problematic code fragment is determined; Using the large language model, based on the rules and modification suggestions corresponding to the problematic code, the problematic code fragment is repaired to obtain a repaired code fragment, and repair logic is generated. Output the problematic code snippet, the repair code snippet, the repair logic, the rules corresponding to the problematic code, and modification suggestions.

9. The method according to claim 8, characterized in that, After outputting the problematic code snippet, the repair code snippet, the repair logic, the rules corresponding to the problematic code, and the modification suggestions, the method further includes: If the user confirms that the repair code snippet has passed based on the problematic code snippet, the repair logic, the rules corresponding to the problematic code, and the modification suggestions, the repair scope of the repair code snippet is detected to obtain the detection result; If the detection result indicates that the repair code snippet is within its target range, the application operation of the repair code snippet is executed. If the detection result indicates that the repair code snippet exceeds its target range, the application operation of the repair code snippet is intercepted.

10. A code review device, characterized in that, The device includes: An acquisition module is used to acquire first code, the first code including target code and its context information within the target scope; An extension module is used to extend the context information of the target code within the target scope to the complete function information where the target code is located, to obtain a second code; The filtering module is used to filter target rule sets from the original rule set that match both the technical scenario and the code execution logic of the second code; The review module is used to review the second code based on the target rule set using a large language model, and obtain the review results.

11. An electronic device, characterized in that, The electronic device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the code review method as described in any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the code review method as described in any one of claims 1-9.

13. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device performs the code review method as described in any one of claims 1-9.

Images