Code change approval control method and computer program product
Patent Information
- Application Number
- CN202610680141.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-05-18
- Publication Date
- 2026-08-18
AI Technical Summary
然而，现有的文本差异比对工具只能计算出修改了哪几行文本，无法评估代码变更对全局的规范代码架构的影响，导致容易出现对规范代码架构造成负面影响的代码变更通过审批的情况
[0037]为使本发明的目的、技术方案和优点更加清楚，下面结合实施例对本发明的技术方案进行说明。所描述的实施例为本发明的部分实施例，并不构成对保护范围的限制；本领域普通技术人员在未作出创造性劳动的前提下基于本发明获得的其他实施例，均属于本发明保护范围。除非另有定义，本文所使用的技术和科学术语与本领域技术人员通常理解的含义相同。
Smart Images
Figure CN122593830A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of software engineering technology, specifically to a control method for code change approval and a computer program product. Background Technology
[0002] Existing code change review mechanisms primarily rely on text-based diff comparison tools to highlight added, deleted, and modified code, supplemented by static code analysis tools for syntax and known vulnerability checks. However, existing text-based diff comparison tools can only calculate which lines of text were modified and cannot assess the impact of code changes on the overall code architecture. This makes it easy for code changes that negatively impact the code architecture to be approved.
[0003] Therefore, a technical solution is needed to effectively control code change reviews. Summary of the Invention
[0004] This disclosure provides a control method and computer program product for code change approval, which adopts the following technical solution:
[0005] A method for controlling code change approval includes: in response to a code change event, acquiring code text related to the code change event, and performing syntax tree parsing based on the code text to determine one or more syntax tree nodes involved in the code change as change nodes; for each change node, extracting a numerical representation of structural complexity from the syntax tree to characterize the increase in code structural complexity caused by the change node; determining the risk level of the change node based on the numerical representation of structural complexity corresponding to the change node; and performing risk control operations in a code review interface based on the risk level of each change node; wherein the risk control operations include at least: in response to the existence of at least one change node having a high risk level, setting the approval control in the code review interface to an unavailable state, and inserting a view control of a preset height near the code area corresponding to the change node for visual risk warning; the view control includes a risk basis display area for displaying the numerical representation of structural complexity corresponding to the change node.
[0006] The above solution parses code changes down to the syntax tree node level and uses structural complexity values such as cyclomatic complexity increment, syntax tree depth, maximum nesting depth, number of branches, number of conditional expressions, and number of loop structures to determine the risk level, so that the code approval process no longer relies solely on text line-level differences. In cases of high risk, mandatory prompts are created at the interface level by making approval controls unavailable and inserting preset height view controls, thereby reducing the possibility that structural risks are ignored by rapid scrolling.
[0007] As one implementation method, the code text before and after the change is obtained, and a syntax tree before and after the change is generated respectively. The changed nodes are then identified through structured alignment. This approach bases the identification of changed nodes on differences in syntax tree structure, rather than simply differences in text lines, thus improving the accuracy of locating structural changes.
[0008] As one implementation method, this approach determines the isomorphic mapping between the syntax trees before and after the change, and generates syntax tree editing operations such as insertion, deletion, update, or movement for syntax tree nodes where no isomorphic mapping has been established. This method can transform code changes into a computable set of structured editing operations, facilitating subsequent risk quantification.
[0009] As one implementation method, semantic noise filtering is performed on the set of syntax tree editing operations before determining the change nodes, discarding editing operations that have no substantial semantic impact, such as whitespace characters, comments, formatting, and renaming. This approach can reduce the interference of low-value text changes on the assessment of structural complexity.
[0010] As one implementation method, the modified node is used as the processing object. Basic node information, host context information, and local context information are obtained, and contextual grammatical structure features are generated. Then, a numerical representation of structural complexity is extracted from these features. This approach enables complexity assessment to simultaneously consider the node itself, the parent grammatical environment, and the local subtree structure.
[0011] As one implementation, the process traverses upwards along the parent node pointer to extract host context information such as file path, package name, class name, function name, method signature, control block type, call path, and exception handling structure. It also traverses the subtree of the changed node to extract local context information such as conditional expression structure, branching structure, loop structure, maximum nesting depth, and syntax tree depth. This method can simultaneously capture the macroscopic location and microscopic structure of the changed node.
[0012] As one implementation method, contextual syntax structure features are generated based on the change operation type, node type, parent node type, child node type, method signature, syntax tree depth, maximum nesting depth, number of conditional expressions, number of branches, number of loop structures, cyclomatic complexity increment, literal node type, and hit anti-pattern markers. This method can identify code patterns that easily lead to increased structural complexity, such as hard-coded temporary mappings and unbounded enumerations.
[0013] As one implementation, a structured information payload is generated to characterize code change events, and this payload includes fields for recording numerical representations of the structural complexity of change nodes. This approach enables risk calculation and interface presentation to use a unified data carrier.
[0014] As one implementation method, each change node item includes a node identifier field, a change operation type field, a node type field, a code snippet field, a context information field, and a structure information field. This method can record the location, content, and structural complexity of each change node in a fine-grained manner.
[0015] As one implementation, the structured information payload also includes a code change record identifier field and a code file path field related to the code change. This approach facilitates tracing the source of code change events and subsequent interface association.
[0016] As one implementation method, topological degradation input parameters are calculated based on the numerical characterization of structural complexity, and the risk level is determined based on these parameters. This approach converts the increase in code structural complexity into a comparable risk input.
[0017] As one implementation method, the topology degradation input parameters are determined according to the following formula:
[0018] D_topo=max(0,ΔC)×log2(Depth+1).
[0019] This approach considers both the cyclomatic complexity increment and the syntax tree depth or maximum nesting depth, making the degree of structural degradation a clear and repeatable calculation method.
[0020] As one implementation method, scoring transformation processes such as normalization, truncation, or interval mapping are performed on the topological degradation input parameters, and the risk level is determined based on the relationship between the risk score and a preset risk threshold. This method facilitates mapping continuous calculation results to discrete risk levels that can be used in the code review interface.
[0021] As one implementation method, if the risk score is less than or equal to a preset risk threshold, it is determined to be a low-risk level; if it is greater than the preset risk threshold, it is determined to be a medium-risk or high-risk level; and if the difference between the risk score and the threshold exceeds a preset difference, it is determined to be a high-risk level. This method provides clear threshold determination rules for risk level classification.
[0022] As one implementation method, when a code change event includes multiple change nodes, the structural complexity numerical representation and risk level of each change node are determined separately. This approach avoids evaluating risk only at a coarse-grained level based on the overall code change, thereby locating locally high-risk nodes among multiple change nodes.
[0023] As one implementation method, when a change node is classified as low-risk, its corresponding code area is collapsed; when a change node is classified as medium-risk, a warning marker is displayed in the code area or line number sidebar. This approach can allocate review attention according to the level of risk, reducing unnecessary reading of low-risk code.
[0024] As one implementation, the position of the change node in the syntax tree is mapped to a range of code lines in the code review interface, and a view control of a preset height is inserted after the code line corresponding to that range and before the next code line. This method can create visible interline visual barriers in the continuous reading path of the code text.
[0025] As one implementation method, the risk assessment display area also shows at least one of the following: code location, code snippet, numerical representation of structural complexity, risk score, and risk level. This approach improves the interpretability of risk alerts, enabling reviewers to directly understand why approval controls are unavailable.
[0026] 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.
[0027] The above solution enables the software-based distribution and deployment of review methods by providing computer program products.
[0028] In addition, the present invention also provides a control system for code change approval, including one or more program modules, which are used to implement the method described above.
[0029] 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.
[0030] In addition, the present invention 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
[0031] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:
[0032] Figure 1 This is a schematic diagram of the overall process of the code change approval control method according to an embodiment of the present invention;
[0033] Figure 2 This is a schematic diagram of the syntax tree structure alignment and structural complexity extraction process according to an embodiment of the present invention;
[0034] Figure 3 This is a schematic diagram illustrating the logic for determining topology degradation input parameters and risk levels according to an embodiment of the present invention;
[0035] Figure 4This is a schematic diagram illustrating the mapping from risk levels to risk control operations on the code review interface in an embodiment of the present invention.
[0036] Figure 5 This is a schematic diagram of the interface for inserting a preset height view control between lines of code in a high-risk scenario according to an embodiment of the present invention. Detailed Implementation
[0037] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention are described below in conjunction with embodiments. The described embodiments are some embodiments of this invention and do not constitute a limitation on the scope of protection; other embodiments obtained by those skilled in the art based on this invention without creative effort are all within the scope of protection of this invention. Unless otherwise defined, the technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art.
[0038] Example 1
[0039] like Figure 1 As shown, this embodiment provides a control method for code change approval. This method is applicable to the Pull Request review interface and Merge Request review interface of a code hosting platform, the Diff review interface in an integrated development environment plugin, or the code approval page in a continuous integration system. The core of this method is not to determine whether the code can be compiled, but rather to transform the increased structural complexity caused by code changes into a quantifiable risk level, and further into interface-level approval control.
[0040] The method in this embodiment includes step S100: In response to a code change event, obtaining the code text related to the code change event, and performing syntax tree parsing based on the code text to determine one or more syntax tree nodes involved in the code change as change nodes. The code change event can be generated by a commit, merge request, patch file, continuous integration pipeline trigger event, or local editor save event. Compared to line-by-line text differences, syntax tree parsing can convert the code text into a tree structure, thereby locating whether the added, deleted, or updated nodes are conditional statements, loop statements, method calls, return statements, or other nodes with structural significance.
[0041] The method in this embodiment further includes step S200: for each change node, extracting a numerical representation of structural complexity from the syntax tree to characterize the increase in code structural complexity caused by the change node. The numerical representation of structural complexity may include at least one of cyclomatic complexity increment, syntax tree depth, maximum nesting depth, number of branches, number of conditional expressions, and number of loop structures. Here, the numerical representation of structural complexity is a machine-readable value or an enumerated value, rather than a reviewer's subjective judgment.
[0042] The method in this embodiment further includes step S300: determining the risk level of the changed node based on the structural complexity numerical representation corresponding to the changed node. The risk level may include low risk, medium risk, and high risk. The risk level can be determined directly based on a single structural complexity numerical representation, or based on the comprehensive calculation result of multiple structural complexity numerical representations.
[0043] The method in this embodiment further includes step S400: performing risk control operations in the code review interface according to the risk level of each change node. Specifically, in response to the existence of at least one change node with a high risk level, the approval control in the code review interface is set to an unavailable state, and a view control of a preset height is inserted near the code area corresponding to the change node for visual risk warning; the view control includes a risk basis display area for displaying the structural complexity numerical representation corresponding to the change node.
[0044] In this embodiment, the approval control can be a button or operation entry point for completing code change approval, such as "Approve Merge," "Approve," "Merge," or "Pass Review." Setting the approval control to an unavailable state can be achieved through the disabled attribute of the front-end control, permission status interception, submission action interception, or server-side approval status verification. The view control can be a small area widget inserted between lines of code, an inline card, an inline tooltip, or other components that change the layout of the code review interface. Unlike pop-ups or brief prompts, the preset height view control alters the visual space near the code area, ensuring that the reviewer sees the risk evidence during the reading path.
[0045] Example 2
[0046] like Figure 2 As shown in Example 1, this example describes the specific process of code text acquisition, syntax tree parsing, structured alignment, and semantic noise filtering.
[0047] Retrieving code text related to code change events can include retrieving the code text of the file involved in the code change event before and after the change. For example, in a Pull Request scenario, two versions of the same file can be read based on the base commit and head commit; in an editor plugin scenario, the buffer contents before and after saving can be read.
[0048] Syntax tree parsing based on the code text can include performing syntax tree parsing on the code text before and after the change, respectively, to generate a syntax tree before and after the change. The parser can be a Tree-sitter, a multi-language compiler front-end, or other tools capable of generating an abstract syntax tree. The node types in the syntax tree can include method declarations, class declarations, if statements, switch statements, for loops, while loops, call expressions, return statements, literal nodes, etc.
[0049] Identifying one or more syntax tree nodes involved in code changes may include performing structured alignment on the original and new syntax trees, generating a set of syntax tree editing operations, and determining the changed nodes based on this set of operations. Structured alignment may first determine the isomorphic mapping between the two syntax trees; for syntax tree nodes without an isomorphic mapping, at least one syntax tree editing operation (insert, delete, update, or move) is generated.
[0050] As a specific implementation, isomorphic mapping relationships can be established based on node type labels, node text summaries, similarity of child node sets, and the relative position of a node within its parent node. For example, when a method declaration node in the pre-modification syntax tree has the same method name as a method declaration node in the post-modification syntax tree and the similarity of its child node sets exceeds a preset threshold, an isomorphic mapping can be established. If a newly added IfStatement node in the post-modification syntax tree cannot find a corresponding node in the pre-modification syntax tree, an Insert type syntax tree editing operation is generated, and the IfStatement node is identified as the modified node.
[0051] Before determining the change node based on the set of syntax tree edit operations, semantic noise filtering can be performed on the set of syntax tree edit operations to discard those involving semantic noise. Edit operations involving semantic noise can include at least one of whitespace characters, comments, formatting, and renaming; edit operations not involving semantic noise can include at least one of control flow, business logic, status judgment, exception handling, call relationships, and architectural boundaries.
[0052] The purpose of semantic noise filtering is to prevent a large number of formatting operations from diluting risk signals. For example, the same commit may contain both indentation changes caused by formatting tools and a newly added deep if branch. If the system directly treats all text changes as sources of risk, reviewers will still be overwhelmed by meaningless differences; by filtering out editing operations such as whitespace, comments, and formatting, subsequent structural complexity assessments can focus on syntax tree nodes that actually change the control flow or call relationships.
[0053] Example 3
[0054] Based on Embodiment 1 or Embodiment 2, this embodiment describes the method for extracting the numerical representation of structural complexity. For each changed node, extracting the numerical representation of structural complexity from the syntax tree may include: taking the changed node as the processing object, obtaining the node's basic information, host context information, and local context information; generating the contextual grammatical structure feature corresponding to the changed node based on the node's basic information, host context information, and local context information; and extracting the numerical representation of structural complexity from the contextual grammatical structure feature.
[0055] Node basic information can include the change operation type and node type. For example, the change operation type can be Insert, Delete, Update, or Move, and the node type can be IfStatement, SwitchStatement, ForStatement, WhileStatement, MethodDeclaration, or CallExpression. Node basic information describes the type of structural change the node itself is undergoing.
[0056] Host context information is used to characterize the parent syntax structure of the modified node in the syntax tree. When obtaining host context information, one can traverse upwards along the parent node pointers from the modified node until the root node of the syntax tree is reached or a preset stopping condition is met. During the traversal, at least one of the following is extracted: file path, package name, class name, function name, method signature, control block type, call path, and exception handling structure. Host context information can indicate whether the same newly added if branch is located in a regular utility function or a core transaction method. Although the risk level of this sub-case is mainly determined by the numerical characterization of structural complexity, the host context can still be used to determine structure-related fields such as syntax tree depth, control block type, and code location.
[0057] Local context information is used to characterize the local syntax structure and local code content of the modified node itself and its subtrees. When obtaining local context information, one can traverse the subtree of the modified node, starting from that node, and extract at least one of the following: child node type, conditional expression structure, branching structure, looping structure, call expression structure, return statement structure, literal node type, maximum nesting depth, and syntax tree depth. Local context information is directly used to calculate structural complexity metrics such as the number of conditional expressions, branches, loops, and maximum nesting depth.
[0058] When generating the contextual syntax structure features corresponding to the change node, it can be generated based on at least one of the following: change operation type, node type, parent node type, child node type, file path, class name, method signature, control block type, call path, exception handling structure, syntax tree depth, maximum nesting depth, number of conditional expressions, number of branches, number of loop structures, cyclomatic complexity increment, literal node type, and matched anti-pattern markers. Anti-pattern markers can include hard-coded temporary mapping markers or unbounded enumeration markers. Unbounded enumeration markers can be used to characterize the syntax tree structure in a switch statement where string literals are used as branch matching values; hard-coded temporary mapping markers can be used to characterize the syntax tree structure in an if statement where string literals are used as comparison objects.
[0059] For example, when a new node is an IfStatement and its conditional expression is gateway_type == "NEW_CRYPTO", the system can recognize this node as a new conditional expression, and simultaneously record the cyclomatic complexity increment as 1, the number of conditional expressions as 1, the number of branches as 1, and record a hard-coded temporary mapping mark because the string literal is used as the comparison object. If the IfStatement is located inside an existing multi-level if or try block, the system can also record the syntax tree depth and maximum nesting depth of the changed node.
[0060] This embodiment can also generate a structured information payload to characterize code change events. The structured information payload includes at least one or more change node items, and each change node item includes one or more fields for recording the numerical representation of the structural complexity corresponding to the change node. Each change node item may include at least a node identifier field, a change operation type field, a node type field, a code snippet field, a context information field, and a structure information field; the context information field may include at least one of a class name field, a method signature field, and a syntax tree depth field; the structure information field may include at least one of a cyclomatic complexity increment field, a static anti-pattern hit label field, and a literal field. The structured information payload may also include basic code change information items, which include a code change record identifier field and a path field for the code file involved in the code change.
[0061] The following is an example of a structured information payload, illustrating how change nodes are recorded as data objects that can be read by subsequent risk calculations and interface displays. In the example below, the comments on the right side of each line explain the meaning of the corresponding field:
[0062] / / Start of structured loads
[0063] "change_id": "commit_8a7b6c_file_payment_ts", / / Change record ID
[0064] "file_path": "src / domain / payment / PaymentGateway.ts", / / Change the file path
[0065] "ast_changes": [ / / List of AST change nodes]
[0066] { / / Single AST change node
[0067] "operation_type": "Insert", / / Edit operation type
[0068] "node_type": "IfStatement", / / Node type
[0069] "code_snippet": "if (gateway_type === 'NEW_CRYPTO') { ...}", / / Code snippet
[0070] "context": { / / Node context
[0071] "class_name": "PaymentProcessor", / / Class name
[0072] "method_signature": "public async processPayment(...)", / / Method signature
[0073] "depth_in_tree": 5 / / Syntax tree depth
[0074] }, / / End of node context
[0075] "structural_features": { / / Structural features
[0076] "cyclomatic_complexity_increment": 1, / / Cyclomatic complexity increment
[0077] "static_anti_patterns_detected": [ / / List of antipatterns]
[0078] "anti_pattern.hardcoded_if_mapping" / / Hardcoded if mapping flag
[0079] ], / / End of anti-pattern list
[0080] "extracted_literals": ["NEW_CRYPTO"] / / Extracted literals
[0081] / / End of structural features
[0082] / / End of single AST change node
[0083] / / End of AST change node list
[0084] / / End of structured load
[0085] Example 4
[0086] like Figure 3 As shown, based on Examples 1 to 3, this example explains the specific method for determining the risk level based on the numerical characterization of structural complexity.
[0087] Determining the risk level based on the numerical representation of the structural complexity corresponding to the changed node may include: calculating the topology degradation input parameters corresponding to the changed node based on the numerical representation of the structural complexity corresponding to the changed node; wherein the numerical representation of the structural complexity corresponding to the changed node is positively correlated with the topology degradation input parameters corresponding to the changed node; and determining the risk level of the changed node based on the topology degradation input parameters.
[0088] In one specific implementation, the topology degradation input parameter corresponding to the changed node is determined as follows: D_topo = max(0, ΔC) × log2(Depth + 1). Here, D_topo represents the topology degradation input parameter, ΔC represents the cyclomatic complexity increment corresponding to the changed node, and Depth represents the syntax tree depth or maximum nesting depth corresponding to the changed node.
[0089] The above formula means that when the cyclomatic complexity increment is negative or does not increase, the topological degeneracy input is not increased due to this term; when the cyclomatic complexity increases due to the addition of conditional branches, loop structures, or abnormal branches, the topological degeneracy input parameter increases with ΔC. Simultaneously, a depth factor is introduced through log2(Depth+1), so that the same cyclomatic complexity increment produces a higher topological degeneracy input at deeper nesting positions. In this way, the system can distinguish between simple branch additions at the top level and branch additions in deep nesting.
[0090] For example, if adding an IfStatement increases the cyclomatic complexity by ΔC=1, and the syntax tree depth of that node is Depth=3, then D_topo=max(0,1)×log2(4)=2. If another new branch increases ΔC=3, and is in a deep nest with Depth=7, then D_topo=max(0,3)×log2(8)=9. The latter has a significantly higher topological degradation input, and therefore is more likely to be classified as medium or high risk.
[0091] Determining the risk level based on topology degradation input parameters may include: performing a scoring transformation process on the topology degradation input parameters to obtain a risk score for the changed node; wherein the scoring transformation process includes at least one of normalization processing, truncation processing, and interval mapping processing; and determining the risk level of the changed node based on the relationship between the risk score of the changed node and a preset risk threshold.
[0092] As an example, D_topo can be truncated to obtain a risk score between 0 and 10, or D_topo can be mapped to a score between 0 and 100 according to a preset range. If the risk score of the changed node is less than or equal to the preset risk threshold, the risk level is low risk; if the risk score is greater than the preset risk threshold, the risk level is medium risk or high risk; if the difference between the risk score and the preset risk threshold is greater than a preset difference, the risk level is high risk.
[0093] When a code change event includes multiple change nodes, the system determines the structural complexity numerical representation corresponding to each change node and the risk level corresponding to each change node. In this way, even if a commit includes changes to multiple files or functions, the system can still locate the risk to a specific syntax tree node and a specific code region, rather than just outputting a general risk for the entire commit.
[0094] Example 5
[0095] like Figure 4 and Figure 5 As shown, based on Examples 1 to 4, this example describes the risk control operations in the code review interface.
[0096] When the risk level of a change node is low, risk control operations can include collapsing the code region corresponding to that change node. For example, for changes with relatively small numerical representations of structural complexity that do not significantly increase cyclomatic complexity or nesting depth, the system can automatically collapse the corresponding code block in the code review interface, allowing reviewers to prioritize attention to changes with higher risk.
[0097] When the risk level of a changed node is medium risk, risk control actions may include displaying a warning marker in the code area or line number sidebar corresponding to the changed node. For example, the system may display a yellow warning icon in the line number sidebar or display a clickable prompt next to the changed code area to alert the reviewer that the node has increased structural complexity, but without directly disabling the approval controls.
[0098] When at least one change node has a high-risk level, the risk control operation includes at least setting the approval control in the code review interface to an unavailable state and inserting a view control of a preset height near the code area corresponding to the change node. This view control includes a risk basis display area, used to display the numerical representation of the structural complexity corresponding to the change node. The unavailable state of the approval control can be implemented through front-end control property settings or through the back-end approval interface rejecting approval requests when a high-risk state is detected.
[0099] Inserting a view control of a preset height near the code area corresponding to the change node can include: mapping the position of the change node in the syntax tree to a range of code lines in the code review interface; and inserting the view control of the preset height after the code line corresponding to the range of code lines and before the next code line. Specifically, syntax tree nodes typically include a start line number, an end line number, a start column number, and an end column number. The system can map this positional information to startLine and endLine in the code review interface and insert the view control after endLine.
[0100] In environments such as Monaco Editor, VS Code Webview, and Diff views on code hosting platforms, the aforementioned preset height view controls can be implemented using view areas, inline components, DOM placeholder nodes, or virtual scrolling list inserts. For example, the system can call the editor's ViewZone interface to create an inline area with a height of 120 to 220 pixels after the target line of code, and attach a risk information card to this area. This card can display information such as cyclomatic complexity increment, syntax tree depth, maximum nesting depth, number of branches, number of conditional expressions, number of loop structures, risk score, and risk level.
[0101] The risk basis display area can also show at least one of the following for the change node: code location, code snippet, numerical representation of structural complexity, risk score, and risk level. For example, for a newly added hard-coded if branch, the risk basis display area can show "Code location: line 120", "Code snippet: if (gateway_type === "NEW_CRYPTO")", "Structural complexity numerical representation: ΔC=1, Depth=5, Maximum nesting depth=4", "Risk score: 4.6", and "Risk level: High risk". By directly placing the numerical basis into the inline view control, reviewers can understand why the approval controls are disabled.
[0102] The view control in this embodiment differs from ordinary pop-ups or temporary notifications. Pop-ups can be closed, and temporary notifications may disappear after a short time, while the preset-height view control inserted between lines of code alters the layout of the code review interface, making high-risk warnings part of the code reading path. This visual alert can effectively mitigate the risk oversight caused by reviewers rapidly scrolling through numerous diffs.
[0103] Example 6
[0104] This embodiment provides a running scenario to illustrate the collaborative execution process of the above embodiments.
[0105] In step S601, the system receives a Pull Request event. This Pull Request modifies the src / domain / payment / PaymentGateway.ts file by adding an if branch to the processPayment method to handle the new payment channel. The system reads the original and modified code text of this file.
[0106] In step S602, the system performs syntax tree parsing on the code text before and after the change, generating a syntax tree before and after the change, and performs structured alignment. Since a new IfStatement node appears in the changed syntax tree and no isomorphic mapping is established in the original syntax tree, the system generates an Insert type syntax tree editing operation and identifies this IfStatement node as the changed node.
[0107] In step S603, the system extracts the basic node information, host context information, and local context information for the changed node. The basic node information shows that the node is an IfStatement of type Insert; the host context information shows that it is located in the processPayment method of the PaymentProcessor class; the local context information shows that the IfStatement includes a string literal comparison condition and a return statement. The system further obtains a numerical representation of the structural complexity: cyclomatic complexity increment ΔC=1, syntax tree depth Depth=5, maximum nesting depth is 4, number of branches is 1, number of conditional expressions is 1, and number of loop structures is 0.
[0108] In step S604, the system calculates the topology degradation input parameters. Taking D_topo=max(0,ΔC)×log2(Depth+1) as an example, D_topo=max(0,1)×log2(6), which is approximately 2.58. After performing interval mapping and truncation processing on the topology degradation input parameters, the system obtains a risk score and determines the changed node as a high-risk level based on the preset risk threshold and the preset difference.
[0109] In step S605, the system maps the position of the change node in the syntax tree to the range of code lines in the code review interface. For example, if the end line number of the change node is line 120, the system inserts a view control with a height of 180 pixels after line 120 and before line 121. This view control displays the numerical representation of structural complexity, risk score, and risk level, while the system sets the "Approve Merge" approval control to an unavailable state.
[0110] In step S606, the reviewer sees the inline view control in the code review interface. Since this view control is located between the changed code and subsequent code, the reviewer cannot simply ignore the risk warning by scrolling continuously. The reviewer can determine whether it is necessary to require the developer to refactor, reduce nesting, or split conditional branches based on the structural complexity numerical representation in the risk assessment display area.
[0111] Through the above execution process, this embodiment can start from code change events and complete continuous processing of syntax tree parsing, change node identification, structural complexity numerical representation extraction, topology degradation risk scoring, risk level determination, and risk control operations on the code review interface.
[0112] 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.
[0113] In addition, the present invention also provides a control system for code change approval, including one or more program modules, which are used to implement the method described above.
[0114] The above solution enables loosely coupled deployment and collaborative operation of the various components of the review pipeline by providing a modular system.
[0115] 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.
[0116] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention 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 the present invention, as long as they essentially implement the technical principles of one or more embodiments of the present disclosure, should be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.
Claims
1. A control method for code change approval, characterized in that, The method includes: In response to a code change event, obtain the code text related to the code change event, and perform syntax tree parsing based on the code text to determine one or more syntax tree nodes involved in the code change as change nodes; For each change node, extract a numerical representation of structural complexity from the syntax tree to characterize the increase in code structure complexity caused by the change node; the numerical representation of structural complexity includes at least one of the following: cyclomatic complexity increment, syntax tree depth, maximum nesting depth, number of branches, number of conditional expressions, and number of loop structures. The risk level of the change node is determined based on the numerical representation of the structural complexity corresponding to the change node; Risk control operations are performed in the code review interface based on the risk level of each change node; wherein, the risk control operations include at least: In response to the existence of at least one change node with a high risk level, the approval control in the code review interface is set to an unavailable state, and a view control of a preset height is inserted near the code area corresponding to the change node for visual risk warning; the view control includes a risk basis display area for displaying the numerical representation of the structural complexity corresponding to the change node.
2. The method according to claim 1, characterized in that, The code text related to the code change event obtained includes: Obtain the code text of the file involved in the code change event before and after the change; Syntax tree parsing based on the code text includes: Perform syntax tree parsing on the code text before and after the change, respectively, to generate a syntax tree before and a syntax tree after the change; Identify one or more syntax tree nodes involved in the code changes as change nodes, including: Perform structured alignment on the syntax tree before and after the change to generate a set of syntax tree editing operations, and determine one or more syntax tree nodes based on the set of syntax tree editing operations; Perform structured alignment on the syntax tree before and after the change to generate a set of syntax tree editing operations, including: Determine the isomorphic mapping relationship between the syntax tree before the change and the syntax tree after the change; For syntax tree nodes that do not have an isomorphic mapping, generate at least one syntax tree editing operation among insertion, deletion, update, or move to obtain a set of syntax tree editing operations; Before determining the one or more change nodes based on the set of syntax tree edit operations, the method further includes: Semantic noise filtering is performed on the set of syntax tree edit operations, discarding syntax tree edit operations involving semantic noise; Among them, syntax tree editing operations involving semantic noise include at least one of whitespace characters, comments, formatting, and renaming; syntax tree editing operations not involving semantic noise include at least one of control flow, business logic, state judgment, exception handling, call relationship, and architecture boundary.
3. The method according to claim 1, characterized in that, For each change node, extract a numerical representation of structural complexity from the syntax tree to characterize the increase in code structural complexity caused by that change node, including: Taking the changed node as the processing object, obtain the node basic information, host context information and local context information corresponding to the changed node; wherein, the node basic information includes the change operation type and node type, the host context information is used to characterize the upper-level syntax structure of the changed node in the syntax tree, and the local context information is used to characterize the local syntax structure and local code content of the changed node itself and its subtrees. Based on the node's basic information, the host context information, and the local context information, generate the contextual syntax structure features corresponding to the changed node; Extract the numerical representation of the structural complexity from the context syntax structure features corresponding to the change node; Obtaining the host context information includes: Starting from the changed node, traverse upwards along the parent node pointer until the root node of the syntax tree is reached or the preset stopping condition is met. During the traversal, extract at least one of the following: file path, package name, class name, function name, method signature, control block type, call path, and exception handling structure of the changed node. Obtaining the local context information includes: Starting from the changed node, traverse the subtree of the changed node and extract at least one of the following: child node type, conditional expression structure, branch structure, loop structure, call expression structure, return statement structure, literal node type, maximum nesting depth, and syntax tree depth.
4. The method according to claim 1, characterized in that, Also includes: Generate a structured information payload to characterize the code change event; wherein the structured information payload includes at least one or more change node items, and each change node item includes one or more fields for recording the numerical representation of the structural complexity corresponding to the change node; Each change node item should include at least the following fields: Node identifier field, change operation type field, node type field, code snippet field, context information field, structure information field; The context information field includes at least one of the following: class name field, method signature field, and syntax tree depth field; The structural information fields include a cyclomatic complexity increment field, a static anti-pattern hit label field, and a literal field.
5. The method according to claim 1, characterized in that, Based on the numerical representation of the structural complexity corresponding to the change node, determine the risk level of the change node, including: Based on the numerical representation of the structural complexity corresponding to the changed node, the topology degradation input parameters corresponding to the changed node are calculated; wherein, the numerical representation of the structural complexity corresponding to the changed node is positively correlated with the topology degradation input parameters corresponding to the changed node; The risk level of the changed node is determined based on the topology degradation input parameters.
6. The method according to claim 5, characterized in that, The risk level of the changed node is determined based on the topology degradation input parameters, including: A scoring transformation process is performed on the topology degradation input parameters to obtain the risk score of the changed node; wherein the scoring transformation process includes at least one of normalization processing, truncation processing, and interval mapping processing; If the risk score of the changed node is less than or equal to the preset risk threshold, then the risk level is a low risk level. If the risk score of the changed node is greater than the preset risk threshold, then the risk level is medium risk or high risk. If the difference between the risk score of the changed node and the preset risk threshold is greater than the preset difference, then the risk level is a high-risk level.
7. The method according to claim 1, characterized in that, The risk control operation also includes at least one of the following: When the risk level of the change node is low risk, perform a collapse operation on the code region corresponding to the change node. Alternatively, when the risk level of the change node is medium risk, a warning marker can be displayed in the code area or line number sidebar corresponding to the change node.
8. The method according to claim 1, characterized in that, Insert a view control of a preset height near the code area corresponding to the change node, including: Map the position of the change node in the syntax tree to the range of code lines in the code review interface; Insert a view control of the preset height after the code line corresponding to the code line range and before the next code line.
9. The method according to claim 1, characterized in that, The risk basis display area also displays at least one of the following risk bases: The change node's code location, code snippet, numerical representation of structural complexity, risk score, and risk level are at least one of the following:
10. A computer program product, characterized in that, It stores at least one instruction, which, when executed by a processor, implements the method of any one of claims 1-9.