Computer-implemented code review method and computer program product

Abstract

The present disclosure provides a computer-implemented code review method and a computer program product. A probe rule library is pre-configured to detect syntax structures that violate a standard code architecture; a code change difference text stream is obtained and parsed to generate a syntax tree forest subset to which a change node belongs; a depth-first traversal is performed on the syntax tree forest subset, a syntax tree node of a type that hits a probe rule trigger type is called according to a corresponding scoring strategy to obtain a structure damage degree score; a high-risk determination is performed based on the structure damage degree score, and a syntax tree node that meets a high-risk trigger condition is determined as a high-risk node; and after the traversal is completed, a high-risk node set is output to determine a review result. The present disclosure can perform low-delay static detection and positioning on structural risks involved in code changes, and improve the recognition efficiency of code review on syntax structures that violate the standard code architecture.

Description

Technical Field

[0001] This disclosure relates to the field of software engineering technology, specifically to a computer-implemented code review method and a computer program product. Background Technology

[0002] In software development, code changes can originate from manual coding by developers, auto-completion in integrated development environments, output from code generation tools, or batch modifications before submission. To ensure that code changes meet the project's requirements for standardized code architecture, it is typically necessary to automatically review the code changes before they enter the subsequent compilation, merging, or release process.

[0003] In automated code review scenarios, code changes are often submitted as a stream of difference text, such as file-level difference text, commit patches, or incremental text in the edit buffer. This type of difference text stream only expresses the location of additions, deletions, and modifications in the code text, while violations of standard code architecture often manifest at the syntactic structure level, such as excessive branch stacking, literal special cases in business logic, or new conditional branches without corresponding abstract implementations. Performing a comprehensive analysis of the entire codebase directly would increase review latency; checking only lines of text makes it difficult to accurately locate syntactic nodes with structural risks.

[0004] Therefore, a more effective code review scheme is needed. Summary of the Invention

[0005] This disclosure provides a computer-implemented code review method and a computer program product, employing the following technical solution:

[0006] A computer-implemented code review method includes a pre-set probe rule base for detecting syntactic structures that violate code architecture guidelines. The computer includes a memory and a processor; the memory stores a computer program adapted to be loaded and executed by the processor. The method includes: acquiring a code change difference text stream; parsing the code change difference text stream to generate a subset of the syntax tree forest to which the changed nodes belong; performing a depth-first traversal of the subset of the syntax tree forest, traversing each syntax tree node in the subset of the syntax tree forest; for the currently traversed syntax tree node, if the node type of the syntax tree node matches the trigger type associated with any probe rule in the probe rule base, then calling the scoring strategy associated with the probe rule to obtain the structural damage score of the syntax tree node; if the node type of the syntax tree node does not match the trigger type associated with any probe rule in the probe rule base, then skipping the syntax tree node and continuing to traverse the next syntax tree node; executing high-risk determination logic based on the structural damage score, and determining the syntax tree node as a high-risk node in response to meeting the preset high-risk trigger conditions; after the traversal is completed, outputting a set of high-risk nodes to determine the review result.

[0007] The above solution parses the code change difference text stream into a subset of the syntax tree forest to which the changed nodes belong, and triggers matching based on the node type according to the probe rule base. It can obtain the structural destruction score and the set of high-risk nodes by only traversing the relevant changed syntax structure. This solution enables code review to deterministically filter and locate syntax structures that violate the standard code architecture without relying on full manual reading, thereby meeting the technical requirement of low-latency identification of structural risks.

[0008] As one implementation, the probe rule base includes unbounded enumeration probe rules. The triggering types of the unbounded enumeration probe rules include switch statement node types and if statement node types. The scoring strategy associated with the probe rule is invoked to obtain the structural destruction score of the syntax tree node, including: responding to the fact that the node type of the currently traversed syntax tree node is a switch statement node type or an if statement node type, counting the number of branches within the syntax tree node; if the number of branches exceeds a preset branch safety threshold, and the class declaration node to which the syntax tree node belongs does not contain an implementation clause, then calculating the structural destruction score based on the difference between the number of branches and the branch safety threshold.

[0009] The above scheme identifies syntax structures that replace structured extension mechanisms with a large number of conditional branches by counting the number of control flow branches and judging whether the class declaration node contains an implementation clause.

[0010] In one implementation, the structural damage score is positively correlated with the difference between the number of branches exceeding the branch safety threshold.

[0011] As one implementation method, the structural damage score is calculated based on the difference between the number of branches and the branch safety threshold, using the following formula:

[0012] S_ast = min(1.0, (branch_count - safe_threshold) × 0.2 + 0.5);

[0013] Where S_ast represents the structural damage score, branch_count represents the number of branches, safe_threshold represents the branch safety threshold, and min represents the minimum value operator.

[0014] The above scheme increases linearly and sets an upper limit, so that the more branches exceed the safety threshold, the higher the corresponding structural damage score, while limiting the score within a preset range.

[0015] In one implementation, the probe rule base includes hard-coded mapping probe rules, and the trigger type of the hard-coded mapping probe rules includes binary expression node types. The scoring strategy associated with the probe rule is invoked to obtain the structural destruction score of the syntax tree node, including: in response to the node type of the currently traversed syntax tree node being a binary expression node type, extracting the operator, left operand, and right operand of the syntax tree node; determining whether the operator belongs to the set of equality comparison operators, and whether one of the left operand and the right operand is a variable identifier type and the other is a literal type; if the operator belongs to the set of equality comparison operators, and the left operand and the right operand satisfy the condition that one is a variable identifier type and the other is a literal type, then determining whether the parent node of the syntax tree node is a conditional statement node; if the parent node of the syntax tree node is a conditional statement node, then returning a preset hard-coded mapping destruction score as the structural destruction score of the syntax tree node.

[0016] The above scheme can structurally locate specific numbers, strings, or Boolean values ​​in business logic by identifying the equality between variable identifiers and literals in conditional judgments.

[0017] As one implementation, the set of equality comparison operators includes at least one of the following: equal operator, strict equal operator, not equal operator, and strict not equal operator; the variable identifier type includes at least one of the following: identifier node type and member expression node type; the literal type includes at least one of the following: numeric literal node type, string literal node type, and boolean literal node type.

[0018] In one implementation, the probe rule base includes isolated branch probe rules, and the trigger type of the isolated branch probe rules includes method declaration node type. Calling the scoring strategy associated with the probe rule to obtain the structural destruction score of the syntax tree node includes: in response to the node type of the currently traversed syntax tree node being a method declaration node, identifying the newly added conditional branch within the method declaration node; extracting the newly added identifier from the newly added conditional branch; searching for the class definition or function definition corresponding to the newly added identifier in the current code file and related code files; if no class definition or function definition corresponding to the newly added identifier is found, and the class declaration node to which the method declaration node belongs contains an implementation clause, then returning a preset isolated branch destruction score as the structural destruction score of the syntax tree node.

[0019] The above scheme can identify isolated branch structures by searching and verifying the newly added identifiers in the newly added conditional branches.

[0020] As one implementation, each probe rule in the probe rule base includes: a trigger type field, used to store the syntax tree node type that triggers the probe rule; a detection logic field, used to store the execution logic of the probe detection operator; and a scoring strategy field, used to store the calculation method of the structural damage score.

[0021] The above solution separates and stores the trigger type, detection logic, and scoring strategy, enabling the probe rule base to quickly filter candidate rules according to node type during traversal and execute the corresponding scoring strategy after a match.

[0022] In one implementation, the high-risk node set includes a high-risk feature object corresponding to each high-risk node. The high-risk feature object includes: a syntax tree fingerprint field, used to store the unique memory identifier of the high-risk node in the syntax tree structure; a file path field, used to store the code file path to which the high-risk node belongs; a byte offset start position field, used to store the starting byte position of the code slice corresponding to the high-risk node in the code file; a byte offset end position field, used to store the ending byte position of the code slice corresponding to the high-risk node in the code file; a trigger probe type field, used to store the probe rule type identifier that triggers the detection; an extracted symbol field, used to store a list of relevant symbol names extracted from the high-risk node; and a structural damage score field, used to store the structural damage score of the high-risk node.

[0023] The above solution encapsulates syntax tree location information, file location information, trigger rule information, and scoring information in a unified manner through high-risk feature objects, which facilitates the subsequent generation of review results, display of alarm locations, or formation of remediation suggestions.

[0024] As one implementation method, after the traversal is completed, if the set of high-risk nodes contains multiple high-risk nodes, the structural damage scores of each of the multiple high-risk nodes are aggregated to obtain the aggregated damage score.

[0025] In one implementation, the aggregation calculation is such that: if the structural damage score of a single high-risk node is greater than a preset high score threshold, then the aggregated damage score is greater than the preset high score threshold; if the structural damage scores of multiple high-risk nodes are all less than a preset low score threshold, then the aggregated damage score is greater than the preset high score threshold; the preset high score threshold is greater than M times the preset low score threshold, where M is greater than 1.

[0026] As one implementation method, the structural damage scores of multiple high-risk nodes are aggregated and calculated using the following nonlinear exponential decay penalty function:

[0027] S_total = 1 - product_{i=1 to n} (1 - S_i);

[0028] Where S_total represents the aggregated destruction score, S_i represents the structural destruction score of the i-th high-risk feature object, n represents the number of high-risk feature objects, and product represents the cumulative multiplication operation.

[0029] The above scheme uses a nonlinear aggregation method to ensure that both a single high-risk node and multiple medium- and low-risk nodes can be reflected in the overall structural risk, and avoids score overshooting caused by simple linear addition.

[0030] As one implementation method, the step of obtaining the code change difference text stream, parsing the code change difference text stream, and generating a subset of the syntax tree forest to which the change nodes belong includes: receiving the original byte stream data of the code change difference file; calling a syntax parser to perform incremental syntax parsing on the original byte stream data; extracting all syntax tree nodes related to this code change, and constructing a syntax tree forest subset specific to the change.

[0031] The above approach uses incremental syntax parsing and change node extraction to build only a subset of the syntax tree forest related to the current code change, which helps reduce the computational load for review.

[0032] As one implementation method, the method further includes: determining whether the high-risk node set is empty; if the high-risk node set is empty, generating a release status code and ending the current code review process.

[0033] In one implementation, the method further includes: generating an interception command to block code changes in response to the aggregated destructiveness score exceeding a preset risk threshold; and generating a release status code to allow code changes in response to the aggregated destructiveness score not exceeding the preset risk threshold.

[0034] The above scheme achieves a deterministic transformation from structural detection results to review status by judging whether the high-risk node set is empty and judging the aggregation damage threshold.

[0035] As one implementation, the probe rule base also includes extensible custom probe rules. The configuration method for the custom probe rules includes: receiving user-inputted custom rule configurations, whereby the custom rule configurations include trigger type, detection logic, and scoring strategy; generating new probe rules based on the custom rule configurations and adding them to the probe rule base.

[0036] The above approach enables the probe rule base to be extended according to the code architecture specifications of different projects.

[0037] As one implementation, after outputting the set of high-risk nodes, the method further includes: converting the set of high-risk nodes into a list of diagnostic objects in Language Server Protocol (LSP) format; and sending the list of diagnostic objects to a code editing environment for display.

[0038] As one implementation, each diagnostic object in the diagnostic object list includes: a Uniform Resource Identifier field for storing the path of the alarm code file; a diagnostic information field for storing at least one of the location range information, severity information, and alarm message of the corresponding high-risk node; and a quick repair field for storing repair suggestions, which include a repair suggestion title and code replacement instructions.

[0039] The above solution converts the set of high-risk nodes into a list of diagnostic objects in LSP format, enabling the code editing environment to visualize high-risk code based on file path and location range, and providing developers with a quick fix entry point.

[0040] In addition, the present invention also provides a computer program product having at least one instruction stored thereon, wherein the at least one instruction, when executed by a processor, implements the method described above.

[0041] The above solution enables the software-based distribution and deployment of review methods by providing computer program products.

[0042] In addition, the present invention provides a code review system, including one or more program modules, which are used to implement the method described above.

[0043] The above solution enables loosely coupled deployment and collaborative operation of the various components of the review pipeline by providing a modular system.

[0044] Furthermore, the present invention also provides a computer device, comprising: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and executed as described above.

[0045] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the method described above. Attached Figure Description

[0046] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0047] Figure 1 This is a flowchart of the destructive mode detection rules;

[0048] Figure 2 This is a schematic diagram of the structure of a computer device. Detailed Implementation

[0049] To make the objectives, technical solutions, and advantages of this disclosure clearer, the technical solutions of this disclosure are described below in conjunction with embodiments. The described embodiments are only some embodiments of this disclosure and do not constitute a limitation on the scope of protection; other embodiments obtained by those skilled in the art based on this disclosure without inventive effort are all within the scope of protection of this disclosure. Unless otherwise defined, the technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art.

[0050] Example 1:

[0051] This embodiment provides a computer-implemented code review method for quickly filtering, scoring, and locating syntactic structures that violate code architecture guidelines before code changes enter the subsequent review process. This method pre-sets a probe rule base before execution, which is used to detect syntactic structures that violate the code architecture guidelines.

[0052] The method can be executed by a computer including a memory and a processor. The memory stores a computer program adapted to be loaded and executed by the processor. During execution, the processor can receive code change difference text streams from IDE buffer edit events, Git commit events, or preflight hooks, and use them as input for the current code review.

[0053] Step 101: Obtain the code change difference text stream, parse the code change difference text stream, and generate the syntax tree forest subset to which the change node belongs.

[0054] Specifically, the code change difference text stream can be the raw byte stream data of the code change difference file. The processor calls a syntax parser to perform incremental syntax parsing on the raw byte stream data, extracting all syntax tree nodes related to this code change, and constructing a syntax tree forest subset specific to the change. The syntax parser can be a parsing library capable of deserializing character streams into a tree-like in-memory data structure, such as tree-sitter. By constructing only the syntax tree forest subset to which the changed nodes belong, this embodiment avoids a full scan of the entire codebase, thereby reducing the delay in code review.

[0055] Step 102: Perform a depth-first traversal on the subset of the syntax tree forest, traversing each syntax tree node in the subset of the syntax tree forest one by one.

[0056] Specifically, the processor visits nodes in the syntax tree forest subset using a depth-first search approach, ensuring that every syntax tree node that has been changed or is related to a change is examined sequentially. For nodes that do not meet the probe rule triggering conditions, such as ordinary assignments, variable renaming, or boilerplate code, the processor does not need to proceed to the subsequent scoring logic.

[0057] Step 103: For the currently traversed syntax tree node, determine whether the node type of the syntax tree node matches the trigger type associated with any probe rule in the probe rule base.

[0058] If the node type of the syntax tree node matches the trigger type associated with any probe rule in the probe rule base, then the scoring strategy associated with that probe rule is invoked to obtain the structural destruction score of the syntax tree node. If the node type of the syntax tree node does not match the trigger type associated with any probe rule in the probe rule base, then the syntax tree node is skipped, and the process continues to traverse the next syntax tree node.

[0059] Step 104: Execute high-risk determination logic based on the structural damage score. In response to meeting the preset high-risk triggering conditions, determine the syntax tree node as a high-risk node.

[0060] Specifically, high-risk triggering conditions may include a structural damage score exceeding a preset threshold, or a probe rule returning a non-zero value and meeting the risk requirements of the corresponding rule. For syntax tree nodes that do not exceed the safety threshold, the processor discards the node and continues traversing subsequent nodes; for syntax tree nodes that exceed the safety threshold, the processor instantiates the corresponding high-risk feature object and adds the syntax tree node to the high-risk node set.

[0061] Step 105: After the traversal is complete, output the set of high-risk nodes to determine the review results.

[0062] Specifically, the high-risk node set can be sent to the subsequent review result determination process, or it can be directly used for local risk threshold judgment, generating interception instructions, or converted into a diagnostic object that can be displayed in the code editing environment. If the high-risk node set is empty, it means that the current code change has not triggered the preset probe rules, and the processor can generate a release status code and end the current code review process.

[0063] This embodiment parses the code change difference text stream into a subset of the syntax tree forest to which the changed nodes belong, and combines this with a probe rule base to perform node type matching and structural damage scoring, forming a deterministic first-level filter. This filter can eliminate regular boilerplate code with low computational overhead, while retaining high-risk structures that may cause architectural degradation.

[0064] Example 2:

[0065] This embodiment, based on embodiment 1, explains the probe rule base and node type triggering matching.

[0066] Each probe rule in the probe rule base includes a trigger type field, a detection logic field, and a scoring strategy field. The trigger type field stores the syntax tree node type that triggers the probe rule; the detection logic field stores the execution logic of the probe detection operator; and the scoring strategy field stores the calculation method for the structural damage score.

[0067] As one implementation, the processor maintains a mapping relationship between node types and probe rule types. For example, switch statement node types and if statement node types can be mapped to unbounded enumeration probe rules; binary expression node types can be mapped to hard-coded mapping probe rules; and method declaration node types can be mapped to isolated branch probe rules. When traversing a subset of the syntax tree forest, the processor first reads the node type of the current node and then queries whether a corresponding probe rule exists based on the mapping relationship.

[0068] If the node type of the current node cannot be mapped to any probe rule, the processor skips the node and continues traversing the next node. This approach uses the probe rule base as a physical funnel, allowing only syntactic structures that may trigger structural risks, such as control flow, binary expressions, and method declarations, to enter the scoring logic, thus reducing traversal and detection costs.

[0069] The probe rule base can also include extensible custom probe rules. The configuration method for custom probe rules includes: receiving user-inputted custom rule configurations, which include trigger type, detection logic, and scoring strategy; generating new probe rules based on the custom rule configuration and adding them to the probe rule base. Thus, the system can extend new static probe types to meet the standardized code architecture requirements of different projects.

[0070] Example 3:

[0071] This embodiment describes the unbounded enumeration probe rule based on Embodiment 1 or Embodiment 2. The unbounded enumeration probe rule is used to detect control flow structures where the number of branches exceeds a preset threshold, and its triggering types include switch statement node types and if statement node types.

[0072] During the depth-first traversal, if the node type of the currently traversed syntax tree node is a switch statement node type or an if statement node type, the processor will call the scoring strategy associated with the unbounded enumeration probe rule.

[0073] Specifically, for a switch statement node, the processor counts the number of switch_case nodes within that node as the branch count. For an if statement node, the processor can recursively count the number of else_if chains as the branch count. If the branch count does not exceed a preset branch safety threshold, a score of zero is returned or the node is not considered a high-risk node. If the branch count exceeds the preset branch safety threshold, the processor further checks whether the class declaration node to which the syntax tree node belongs contains an implementation clause.

[0074] If the number of branches exceeds a preset branch safety threshold, and the class declaration node to which the syntax tree node belongs does not contain an implementation clause, then a structural violation score is calculated based on the difference between the number of branches and the branch safety threshold. This determination is used to identify situations in ordinary business classes where stacked if-else or switch-case statements are used to replace the abstract extension mechanism.

[0075] In one implementation, the structural damage score is positively correlated with the difference between the number of branches exceeding the branch safety threshold. The structural damage score can be calculated based on the difference between the number of branches and the branch safety threshold using the following formula:

[0076] S_ast = min(1.0, (branch_count - safe_threshold) × 0.2 + 0.5);

[0077] Where S_ast represents the structural damage score, branch_count represents the number of branches, safe_threshold represents the branch safety threshold, and min represents the minimum value operator.

[0078] The above formula ensures that the fewer the number of branches, the lower the risk; when the number of branches exceeds the safety threshold, the more branches exceed the threshold, the higher the structural damage score, and the upper limit of 1.0 is used to prevent the score from growing indefinitely.

[0079] Example 4:

[0080] This embodiment, based on Embodiment 1 or Embodiment 2, describes the hard-coded mapping probe rules. These hard-coded mapping probe rules are used to detect the equality between variables and literals, and their triggering types include binary expression node types.

[0081] During the depth-first traversal, if the node type of the currently traversed syntax tree node is a binary expression node type, the processor will call the scoring strategy associated with the hard-coded mapping probe rule.

[0082] Specifically, the processor extracts the operator, left operand, and right operand of the binary expression node; determines whether the operator belongs to the set of equality comparison operators, and determines whether one of the left operand and the right operand is a variable identifier type and the other is a literal type. If the operator belongs to the set of equality comparison operators, and the left operand and the right operand satisfy the condition that one is a variable identifier type and the other is a literal type, then the processor further determines whether the parent node of the syntax tree node is a conditional statement node.

[0083] The set of equality comparison operators may include at least one of the following: equals operator, strict equals operator, not equals operator, and strict not equals operator. For example, the operators may be "==", "===", "!=", or "!==". The variable identifier type may include at least one of the following: identifier node type and member expression node type; the literal type may include at least one of the following: numeric literal node type, string literal node type, and boolean literal node type.

[0084] If the parent node of the binary expression node is a conditional statement node, the processor returns a preset hard-coded mapping violation score as the structural violation score of the syntax tree node. This preset score can be 0.8, used to represent the structural risk of directly making special judgments on specific IDs, magic strings, or Boolean literals in the business logic.

[0085] For example, in the code snippet: if (user.id == 10086 || user.id == 10087) {grantAdmin();}, the processor can extract the binary expression node, where the operands include the variable identifier user.id and the numeric literal 10086 or 10087; if this binary expression is located in the conditional part of the if statement, the hard-coded mapping probe rule is triggered and the corresponding structural destruction score is output.

[0086] Example 5:

[0087] This embodiment describes the isolated branch probe rule based on Embodiment 1 or Embodiment 2. The isolated branch probe rule is used to detect situations where a newly added conditional branch has not been synchronously created with a corresponding abstraction layer or processing structure, and its triggering type includes the method declaration node type.

[0088] During the depth-first traversal, if the node type of the currently traversed syntax tree node is a method declaration node type, the processor will invoke the scoring strategy associated with the isolated branch probe rule.

[0089] Specifically, the processor, responding to the fact that the node type of the currently traversed syntax tree node is a method declaration node, identifies newly added conditional branches within that method declaration node. These newly added conditional branches can be newly inserted if statements, switch statements, or their branch fragments in this code change. The processor extracts a new identifier from the newly added conditional branch, which may include a new enumeration value, a business identifier corresponding to a string literal, or a symbol name appearing in the new branch condition.

[0090] Subsequently, the processor searches for the class definition or function definition corresponding to the newly added identifier in the current code file and related code files. If no class definition or function definition corresponding to the newly added identifier is found, and the class declaration node to which the method declaration node belongs contains an implementation clause, the processor returns a preset isolated branch violation score as the structural violation score of the syntax tree node.

[0091] The above judgment is used to identify situations where a new business branch is added but the corresponding class definition, function definition, or abstract extension structure is not created simultaneously. For example, if a conditional branch is added to a class that has already implemented an interface, but no implementation class or processing function corresponding to the added identifier is created, this conditional branch may constitute an isolated branch. The preset isolated branch disruption score can be 0.7, used to quantify its disruption to architectural consistency.

[0092] Figure 1 This is a flowchart of the destructive pattern detection rules. The following is a description of the process: First, the system maps nodes to corresponding probe rules based on the syntax tree node type and discards nodes that cannot be mapped. When a node is a control flow statement, the system counts the number of branches and determines whether it belongs to an unbounded enumeration based on the interface implementation. When a node is a binary expression, the system checks the equality operator, variable identifier, and literal combination, as well as its condition judgment context, to identify hard-coded mappings. When a node is a newly added conditional branch, the system checks whether the corresponding class definition or function definition is missing and whether the class has implemented the interface, to identify isolated branches. Finally, the structural destructive scores of multiple high-risk nodes are non-linearly aggregated.

[0093] Example 6:

[0094] This embodiment describes the set of high-risk nodes and high-risk characteristic objects based on any of the above embodiments.

[0095] The high-risk node set includes a high-risk feature object corresponding to each high-risk node. Each high-risk feature object is used to record, in a structured manner, the location information, triggering rule information, and scoring information of the high-risk node in the syntax tree and source code text.

[0096] As one implementation, the high-risk feature object includes a syntax tree fingerprint field, a file path field, a byte offset start position field, a byte offset end position field, a trigger probe type field, an extraction symbol field, and a structural damage score field.

[0097] The syntax tree fingerprint field stores the unique memory identifier of the high-risk node within the syntax tree structure. The file path field stores the path to the code file to which the high-risk node belongs. The byte offset start position field stores the starting byte position of the code slice corresponding to the high-risk node within the code file. The byte offset end position field stores the ending byte position of the code slice corresponding to the high-risk node within the code file. The trigger probe type field stores the identifier of the probe rule type that triggered the detection. The extracted symbol field stores a list of relevant symbol names extracted from the high-risk node. The structural damage score field stores the structural damage score of the high-risk node.

[0098] Using the aforementioned high-risk feature objects, the processor can convert local high-risk structures in the abstract syntax tree into transitible, cacheable, and displayable data objects. Subsequent processes can locate code text based on the file path and byte offset fields, generate alarm messages based on the trigger probe type field, and perform aggregation calculations or threshold judgments based on the structure damage score field.

[0099] Example 7:

[0100] This embodiment, based on any of the above embodiments, explains the aggregation of structural damage scores for multiple high-risk nodes and the logic for allowing and blocking passage.

[0101] After the traversal is completed, if the set of high-risk nodes contains multiple high-risk nodes, the processor aggregates the structural damage scores of each of the multiple high-risk nodes to obtain an aggregated damage score.

[0102] In one implementation, the aggregation calculation is such that: if the structural damage score of a single high-risk node is greater than a preset high score threshold, then the aggregated damage score is greater than the preset high score threshold; if the structural damage scores of multiple high-risk nodes are all less than a preset low score threshold, then the aggregated damage score can also exceed the preset high score threshold due to the accumulation of multiple low-score risks; the preset high score threshold is greater than M times the preset low score threshold, where M is greater than 1.

[0103] As one implementation method, the structural damage scores of multiple high-risk nodes are aggregated and calculated using the following nonlinear exponential decay penalty function:

[0104] S_total = 1 - product_{i=1 to n} (1 - S_i);

[0105] Where S_total represents the aggregated destruction score, S_i represents the structural destruction score of the i-th high-risk feature object, n represents the number of high-risk feature objects, and product represents the cumulative multiplication operation.

[0106] This aggregation method allows a single extremely high-risk node or multiple slightly risky nodes to drive up the overall score, while avoiding linear accumulation exceeding 1.0. In response to the aggregated destructive score exceeding a preset risk threshold, the processor generates an intercept command to block code changes; in response to the aggregated destructive score not exceeding the preset risk threshold, the processor generates a release status code to allow code changes. If the high-risk node set is empty, the processor can directly generate a release status code and end the current code review process.

[0107] Example 8:

[0108] This embodiment describes the diagnostic object list of the Language Server Protocol (LSP) format, based on any of the above embodiments.

[0109] After outputting the set of high-risk nodes, the processor can convert the set of high-risk nodes into a list of diagnostic objects in the Language Server Protocol (LSP) format, and send the list of diagnostic objects to the code editing environment for display.

[0110] Specifically, each diagnostic object in the diagnostic object list may include a Uniform Resource Identifier (URI) field, a diagnostic information field, and a quick fix field. The URI field stores the path to the alarm code file. The diagnostic information field stores at least one of the following: the location range information of the corresponding high-risk node, its severity information, and the alarm message. The quick fix field stores a fix suggestion, which includes a fix suggestion title and code replacement instructions.

[0111] As one implementation, the processor generates a Uniform Resource Identifier (URI) field based on the file path field in the high-risk feature object, generates location range information based on the byte offset start position field and byte offset end position field, and generates severity information and alarm messages based on the trigger probe type field and structural damage score field. For repairable high-risk nodes, the processor can also generate repair suggestion titles and code replacement instructions, enabling the code editing environment to display the review results in the form of red highlighting, error messages, or QuickFix entries.

[0112] For example, if a hard-coded mapping probe rule hits a binary expression node, the processor can write an alarm message indicating the risk of hard-coded mapping in the diagnostic information field, and use the start and end positions of the corresponding code snippet as the location range information; after receiving the diagnostic object, the code editing environment can display a highlight prompt at the corresponding code position and provide a quick fix entry.

[0113] In addition, the present invention also provides a computer program product having at least one instruction stored thereon, wherein the at least one instruction, when executed by a processor, implements the method described above.

[0114] The above solution enables the software-based distribution and deployment of review methods by providing computer program products.

[0115] In addition, the present invention provides a code review system, including one or more program modules, which are used to implement the method described above.

[0116] The above solution enables loosely coupled deployment and collaborative operation of the various components of the review pipeline by providing a modular system.

[0117] Furthermore, the present invention also provides a computer device, comprising: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and executed as described above. Figure 2 This is a schematic diagram of the structure of a computer device.

[0118] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure, such as using other types of syntax parsers to construct a subset of the syntax tree forest, using other node traversal orders to achieve equivalent node traversal, using other scoring functions that are positively correlated with structural risk and have upper bound constraints to calculate the structural damage score, or using other equivalent data fields to encapsulate high-risk nodes, as long as their essence realizes the static structural detection, scoring, and high-risk node output of the syntax tree nodes corresponding to the code change difference text stream through the probe rule base, should be covered within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of protection of the claims.

Claims

1. A computer-implemented code review method, characterized in that, A pre-defined probe rule base is used to detect syntax structures that violate the code architecture specification. The computer includes a memory and a processor. The memory stores a computer program adapted to be loaded and executed by the processor. The method includes: Obtain the code change difference text stream, parse the code change difference text stream, and generate the syntax tree forest subset to which the change node belongs; A depth-first traversal is performed on the subset of the syntax tree forest, traversing each syntax tree node in the subset of the syntax tree forest one by one; For the currently traversed syntax tree node, if the node type of the syntax tree node matches the trigger type associated with any probe rule in the probe rule library, then the scoring strategy associated with the probe rule is invoked to obtain the structural destruction score of the syntax tree node; if the node type of the syntax tree node does not match the trigger type associated with any probe rule in the probe rule library, then the syntax tree node is skipped and the next syntax tree node is traversed. Based on the structural damage score, high-risk determination logic is executed, and in response to the satisfaction of the preset high-risk triggering condition, the syntax tree node is determined as a high-risk node. After traversal is complete, output the set of high-risk nodes to determine the review results.

2. The method according to claim 1, characterized in that, The probe rule base includes unbounded enumeration probe rules, and the triggering types of the unbounded enumeration probe rules include switch statement node type and if statement node type; The scoring strategy associated with the probe rule is invoked to obtain the structural violation score of the syntax tree node, including: In response to the current syntax tree node being of type switch statement node or if statement node type, count the number of branches within that syntax tree node; If the number of branches exceeds a preset branch safety threshold, and the class declaration node to which the syntax tree node belongs does not contain an implementation clause, then the structural destruction score is calculated based on the difference between the number of branches and the branch safety threshold. The structural damage score is positively correlated with the difference between the number of branches exceeding the branch safety threshold.

3. The method according to claim 1, characterized in that, The probe rule base includes hard-coded mapping probe rules, and the triggering type of the hard-coded mapping probe rules includes binary expression node type; The scoring strategy associated with the probe rule is invoked to obtain the structural violation score of the syntax tree node, including: In response to the fact that the node type of the currently traversed syntax tree node is a binary expression node type, extract the operator, left operand, and right operand of the syntax tree node; Determine whether the operator belongs to the set of equality comparison operators, and that one of the left operand and the right operand is a variable identifier type and the other is a literal type; If the operator belongs to the set of equality comparison operators, and the left operand and the right operand satisfy that one is a variable identifier type and the other is a literal type, then determine whether the parent node of the syntax tree node is a conditional statement node. If the parent node of the syntax tree node is a conditional statement node, then the preset hard-coded mapping violation score is returned as the structural violation score of the syntax tree node. The set of equality comparison operators includes at least one of the following: equal operator, strictly equal operator, not equal operator, and strictly not equal operator. The variable identifier type includes at least one of the identifier node type and the member expression node type; The literal type includes at least one of the following: numeric literal node type, string literal node type, and boolean literal node type.

4. The method according to claim 1, characterized in that, The probe rule base includes isolated branch probe rules, and the triggering type of the isolated branch probe rules includes the method declaration node type; The scoring strategy associated with the probe rule is invoked to obtain the structural violation score of the syntax tree node, including: In response to the fact that the node type of the currently traversed syntax tree node is a method declaration node type, the newly added conditional branch within the method declaration node is identified. Extract the new identifier from the newly added conditional branch; Search the current code file and related code files for the class definition or function definition corresponding to the newly added identifier; If no class definition or function definition corresponding to the newly added identifier is found, and the class declaration node to which the method declaration node belongs contains an implementation clause, then the preset isolated branch destruction score is returned as the structural destruction score of the syntax tree node.

5. The method according to claim 1, characterized in that, The high-risk node set includes a high-risk feature object corresponding to each high-risk node, and the high-risk feature object includes: The syntax tree fingerprint field is used to store the unique memory identifier of the high-risk node in the syntax tree structure; The file path field is used to store the path of the code file to which the high-risk node belongs; The byte offset start position field is used to store the starting byte position of the code slice corresponding to the high-risk node in the code file; The byte offset termination position field is used to store the termination byte position of the code slice corresponding to the high-risk node in the code file; The trigger probe type field is used to store the identifier of the probe rule that triggers the detection; The extracted symbol field is used to store a list of relevant symbol names extracted from the high-risk node; The structural damage score field is used to store the structural damage score of the high-risk node.

6. The method according to claim 1, characterized in that, After the traversal is complete, the method further includes: If the set of high-risk nodes contains multiple high-risk nodes, then the structural damage scores of each of the multiple high-risk nodes are aggregated to obtain an aggregated damage score; wherein, the aggregation calculation is such that: if the structural damage score of a single high-risk node is greater than a preset high score threshold, then the aggregated damage score is greater than the preset high score threshold; if the structural damage scores of multiple high-risk nodes are all less than a preset low score threshold, then the aggregated damage score is greater than the preset high score threshold; the preset high score threshold is greater than M times the preset low score threshold, where M is greater than 1; The method further includes: generating an interception command to block code changes in response to the aggregated destructiveness score exceeding a preset risk threshold; and generating a release status code to allow code changes in response to the aggregated destructiveness score not exceeding the preset risk threshold.

7. The method according to claim 1, characterized in that, The method further includes: Determine whether the set of high-risk nodes is empty; If the set of high-risk nodes is empty, a release status code is generated and the current code review process ends.

8. The method according to claim 1, characterized in that, The probe rule base also includes extensible custom probe rules, which can be configured in the following ways: Receive user input of custom rule configuration, which includes trigger type, detection logic and scoring strategy; New probe rules are generated based on the custom rule configuration and added to the probe rule library.

9. The method according to claim 1, characterized in that, After outputting the set of high-risk nodes, the method further includes: The set of high-risk nodes is converted into a list of diagnostic objects in Language Server Protocol (LSP) format; The list of diagnostic objects is sent to the code editing environment for display; Each diagnostic object in the diagnostic object list includes: The Uniform Resource Identifier field is used to store the path to the alarm code file; The diagnostic information field is used to store at least one of the following: the location range information, severity information, and alarm message of the corresponding high-risk node. A quick fix field is used to store fix suggestions, which include a fix suggestion title and code replacement instructions.

10. A computer program product having at least one instruction stored thereon, wherein the at least one instruction, when executed by a processor, implements the method of any one of claims 1-9.

Images