Computer-implemented code review method and computer program product

Abstract

The disclosure provides a computer-implemented code review method and a computer program product. A decision memory base and a code topology dependency graph are constructed in advance; in response to a code change event, a syntax tree structure corresponding to the code change text is determined, and a plurality of syntax tree nodes of a set type are detected in the syntax tree structure to obtain a set of nodes to be analyzed; according to the set of nodes to be analyzed, a set of code entities to be analyzed is matched in the code topology dependency graph, and an affected code entity set is determined by respectively traversing the dependency relationship in reverse from each code entity to be analyzed as a starting point to obtain an impact range score; according to the code slice corresponding to the set of nodes to be analyzed, semantic similarity retrieval is performed in the decision memory base to determine a decision matching score; and a review result is determined according to the impact range score and the decision matching score. The disclosure can improve the accuracy of the code review result.

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] As software systems continue to grow in scale, the business modules, interfaces, call relationships, and historical design decisions within the codebase become increasingly complex. Modern software development typically employs a collaborative, continuous integration, and rapid iteration development model, significantly increasing the frequency of code changes. Especially with the widespread use of AI-assisted programming tools, developers can generate, modify, and complete code more quickly, further improving code output efficiency.

[0003] In the aforementioned scenarios, code review remains a crucial step in ensuring software quality, architectural consistency, and system stability. Existing code review methods typically include manual review, rule-based static analysis tools, code formatting checks, and automated tools based on discrepancies in the code. These tools can detect some syntax errors, coding style issues, and common security flaws. However, the risks of code changes don't always manifest as local syntax errors or obvious coding style problems. Some code changes may be correct locally, passing compilation, unit tests, and routine static checks, but they could potentially disrupt the overall code architecture on a larger scale.

[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] This disclosure provides a computer-implemented code review method that pre-constructs a decision memory and a code topology dependency graph. The decision memory stores several constraint decisions, and the nodes in the code topology dependency graph represent code entities. Each code entity is a program construction unit with a unique declared path, and the directed edges in the code topology dependency graph represent dependencies between code entities. The computer includes a memory and a processor. The memory stores a computer program adapted to be loaded and executed by the processor.

[0007] The method includes: in response to a code change event, determining a syntax tree structure corresponding to the code change text; detecting several syntax tree nodes of a set type in the syntax tree structure to obtain a set of nodes to be analyzed; wherein the set type includes one of external interface calls, state modifications, and semantic identifiers; matching a set of code entities to be analyzed in the code topology dependency graph based on the set of nodes to be analyzed, and traversing backward along the dependency relationship in the code topology dependency graph starting from each code entity to be analyzed to determine a set of affected code entities; obtaining an impact range score based on the scoring strategy associated with each affected code entity; performing semantic similarity retrieval in the decision memory based on the code slices corresponding to the set of nodes to be analyzed; determining a decision matching score based on the semantic similarity retrieval results; and determining a review result based on the impact range score and the decision matching score.

[0008] The above-mentioned scheme parses code changes into a syntax tree structure and filters out nodes related to external interface calls, state modifications, or semantic identifiers to be analyzed. This allows for the extraction of semantic targets with review value from the code text. At the same time, it determines the affected scope of the code entities to be analyzed through a code topology dependency graph and performs semantic similarity retrieval through a decision memory. This approach can simultaneously consider the topological impact scope of code changes and the degree of matching with historical constraint decisions, thereby providing a more accurate technical basis for the review results.

[0009] As one implementation method, the construction of the code topology dependency graph includes: analyzing the code repository and extracting code entities, wherein the code entities include at least one of classes, interfaces, functions, and methods; assigning a globally qualified symbolic name as a unique identifier to each code entity, wherein the globally qualified symbolic name includes the complete declaration path from the root namespace to the current code entity; identifying the dependency relationships between code entities, wherein the dependency relationships include at least one of call relationships, implementation relationships, inheritance relationships, and module-level dependency relationships; and constructing a code topology dependency graph in a graph database with code entities as nodes and dependency relationships as directed edges.

[0010] The above scheme assigns globally qualified symbol names to code entities and constructs a directed graph of call relationships, implementation relationships, inheritance relationships, and module-level dependencies, enabling the structural dependencies in the code library to be persistently stored and queried by the computer, providing a graph data foundation for subsequent scope traversal.

[0011] In one implementation, each node in the code topology dependency graph is also associated with node attributes, which include at least: a node identifier attribute for storing the globally qualified symbol name of the code entity; an entity type attribute for representing the type of the code entity, including classes, interfaces, and methods; and a decision binding attribute for storing the decision identifier associated with the code entity, which points to the constraint decisions in the decision memory.

[0012] The above scheme binds decision identifiers to nodes in the code topology dependency graph, enabling code entities in the graph database to establish associations with constraint decisions in the decision memory, thereby obtaining historical constraint information related to the code entities simultaneously during topology traversal.

[0013] As one implementation method, a syntax tree structure corresponding to the code change text is determined, and the syntax tree node corresponding to the code change location is located in the syntax tree structure. Specifically, this includes: performing syntax tree parsing based on the code change location and the file path of the code change text to obtain a subset of the syntax tree forest, which serves as the syntax tree structure corresponding to the code change text.

[0014] The above solution uses syntax tree parsing based on code change location and file path to generate local or incremental subsets of syntax tree forests for code change text, reducing the computational overhead of full parsing and improving the response efficiency of code review.

[0015] As one implementation method, the code entity set to be analyzed is obtained by matching the set of nodes to be analyzed in the code topology dependency graph. Specifically, this includes: for each node to be analyzed in the set of nodes to be analyzed, parsing the complete declaration path from the root node to the node to be analyzed from the syntax tree to obtain the globally qualified symbol name corresponding to the node to be analyzed; and matching the corresponding code entity to be analyzed in the code topology dependency graph based on the globally qualified symbol name corresponding to the node to be analyzed.

[0016] The above scheme resolves the complete declaration path from the syntax tree node and converts it into a globally qualified symbol name, enabling local syntax tree nodes to be accurately mapped to persistent code entities in the code topology dependency graph, thus achieving cross-domain addressing between the syntax structure space and the topology dependency space.

[0017] As one implementation, for each node in the set of nodes to be analyzed, the complete declaration path from the root node to the node to be analyzed is parsed from the syntax tree, including: identifying the node type of the node to be analyzed; in response to the node to be analyzed being a declaration node, constructing a globally qualified symbolic name based on the declaration path; in response to the node to be analyzed being a use node, determining the external entity referenced by the use node through symbol resolution; the use node includes an identifier node or an expression node; in response to the external entity not being a parameter, a local variable, or a member of the current class, constructing a globally qualified symbolic name based on the declaration path of the external entity.

[0018] The above scheme distinguishes between declaration nodes and usage nodes. For declaration nodes, it directly constructs a globally qualified symbol name based on the declaration path. For usage nodes, it determines the external entity they reference through symbol resolution. This avoids misidentifying local variables, parameters, or current class members as independent global topological entities, thereby improving the accuracy of code entity matching.

[0019] As one implementation method, in the code topology dependency graph, starting from each code entity to be analyzed, a reverse traversal is performed along the dependency relationship to determine the set of affected code entities. This includes: for each code entity to be analyzed, adding the code entity to be analyzed to a traversal queue and initializing the current traversal depth to zero; retrieving the current node from the traversal queue, querying the directed edge in the code topology dependency graph with the current node as the endpoint, and obtaining the starting node of the directed edge as the upstream node; adding unvisited upstream nodes to the set of affected code entities and recording the number of hops between the upstream node and the code entity to be analyzed; adding the upstream node to the traversal queue, incrementing the traversal depth, and repeating the traversal until the traversal depth reaches a preset maximum depth or the traversal queue is empty.

[0020] The above scheme traverses along the dependencies in reverse order, which can identify which upstream code entities will be affected by changes to the code entity being analyzed. By using access records and maximum depth control, it avoids repeated traversal and infinite propagation, thereby obtaining a computable set of affected code entities.

[0021] As one implementation method, obtaining the impact range score based on the scoring strategy associated with each affected code entity includes: determining the entity weight based on the type of the affected code entity, wherein the weight of the interface type is higher than the weight of the class type, and the weight of the class type is higher than the weight of the method type; for each affected code entity, calculating the impact range score corresponding to the affected code entity based on the entity weight of the affected code entity and the hierarchical distance of the affected code entity relative to the initially traversed code entity to be analyzed, wherein the impact range score is positively correlated with the entity weight and negatively correlated with the hierarchical distance.

[0022] The above scheme incorporates entity weights and hierarchical distances to include the architectural importance and dependency propagation distance of different types of code entities in the scope of influence score, so that core interfaces, core classes and specific methods have different weights in the scope of influence assessment.

[0023] As one implementation method, the impact scope score for each affected code entity is calculated using the following formula:

[0024] P_i = w_i · γ^{d_i};

[0025] Where P_i represents the influence range score corresponding to the i-th affected code entity, w_i represents the entity weight of the i-th affected code entity, d_i represents the hierarchical distance of the i-th affected code entity relative to the code entity to be analyzed at the beginning of the traversal, and γ represents the propagation attenuation factor, γ < 1.

[0026] The above scheme uses a propagation decay factor to exponentially decay the hierarchical distance, so that the influence range score of the affected code entity is lower the farther away from the code entity to be analyzed, thereby simulating the characteristic that the impact of code changes gradually decays as the dependency link extends.

[0027] As one implementation, obtaining the scope of influence score based on the scoring strategy associated with each affected code entity further includes the following steps: fusing and normalizing the scope of influence scores corresponding to all affected code entities to obtain the scope of influence score corresponding to the set of affected code entities.

[0028] The above scheme transforms discrete single-entity scores into a unified impact range score by fusing and normalizing the scores of multiple affected code entities, which facilitates subsequent joint calculation with decision matching scores.

[0029] As one implementation method, the impact range scores corresponding to all affected code entities are merged and normalized using the following formula:

[0030] P_total = sum_{i ∈ V_affected} (w_i · γ^{d_i});

[0031] D_impact=1−exp(−λ⋅P_total);

[0032] Where w_i represents the entity weight of the i-th affected code entity, d_i represents the hierarchical distance of the i-th affected code entity relative to the code entity to be analyzed at the beginning of the traversal, γ represents the propagation attenuation factor, γ < 1, V_affected represents the set of affected nodes, P_total represents the accumulated impact range score, D_impact represents the normalized impact range score, and λ is the sensitivity constant.

[0033] The above scheme accumulates the weighted decay scores of each affected code entity and normalizes them using a negative exponential function, so that the impact range score is mapped to a finite interval, which facilitates stable calculation in risk fusion.

[0034] As one implementation method, the review result is determined based on the scope of impact score and the decision matching score, specifically including: performing a weighted fusion calculation on the scope of impact score and the decision matching score to obtain a risk score; and generating an interception instruction for the code change event in response to the risk score exceeding a preset risk score threshold.

[0035] The above scheme, by weighting and fusing the impact scope score and the decision matching score, can simultaneously consider the topological impact of code changes and the semantic matching degree between them and constraint decisions, and generate an interception instruction when the risk score exceeds the threshold, thereby achieving automated review and control.

[0036] In one implementation, the decision memory also includes a trigger type associated with each constraint decision, where the trigger type is the syntax tree node type that triggers the constraint decision; based on the code slices corresponding to the set of nodes to be analyzed, semantic similarity retrieval is performed in the decision memory, specifically including: matching the type of each node to be analyzed with the trigger type associated with each constraint decision in the decision memory, filtering out the constraint decisions associated with the trigger type that matches the type of any node to be analyzed, forming a target constraint decision set; and performing semantic similarity retrieval in the target constraint decision set based on the code slices corresponding to each node to be analyzed.

[0037] The above scheme pre-screens constraint decisions by trigger type, avoiding including all constraint decisions in semantic similarity retrieval, reducing retrieval computation, and improving the targeting of constraint decision recall.

[0038] In one implementation, the decision memory also includes a decision identifier associated with each constraint decision; the code entities in the code topology dependency graph are associated with decision identifiers; before performing semantic similarity retrieval in the target constraint decision set based on the code slice corresponding to each node to be analyzed, the method further includes: adding the constraint decisions associated with at least some of the code entities to be analyzed and / or at least some of the affected code entities to the target constraint decision set.

[0039] The above scheme adds the constraint decisions that bind the code entities to be analyzed and the affected code entities in the code topology dependency graph to the target constraint decision set, so that semantic retrieval not only relies on node type filtering, but also introduces historical decision constraints related to the current code changes in the topology structure, thereby improving the completeness of the retrieval set.

[0040] As one implementation, the decision memory also includes a decision semantic vector associated with each constraint decision; based on the code slice corresponding to each node to be analyzed, semantic similarity retrieval is performed in the target constraint decision set, specifically including: converting the code slice corresponding to each node to be analyzed into a code semantic vector; calculating the similarity between the code semantic vector corresponding to each node to be analyzed and each decision semantic vector in the target constraint decision set. Based on the semantic similarity retrieval results, a decision matching score is determined, specifically including: sorting the combinations of code slices and constraint decisions from largest to smallest similarity; in response to a maximum similarity greater than a preset similarity threshold, determining the combination of code slices and constraint decisions corresponding to the maximum similarity, and calling a large model to analyze the matching of code slices and constraint decisions within this combination; and determining the decision matching score based on the model analysis results.

[0041] The above scheme determines the semantic similarity between code slices and constraint decisions by calculating the similarity between code semantic vectors and decision semantic vectors. When the maximum similarity is greater than a preset threshold, a large model is called to analyze the matching of code slices and constraint decisions, thereby further determining the decision matching score based on the initial screening by vector retrieval.

[0042] In one implementation, the decision memory includes a vector database, which stores several decision records. Each decision record includes the following fields: a decision identifier field, used to store a unique identifier for the constraint decision; a category field, used to characterize the type of the constraint decision, the type including at least one of design principle, prohibition mode, and historical pitfalls; a trigger type field, used to store the syntax tree node type that triggers the constraint decision; a semantic vector field, used to store the semantic vector representation of the constraint decision, the semantic vector being used for semantic similarity retrieval; a contextual hint field, used to store the rule description text for use by the large language model; and a mandatory rule field, used to store the text description of the enforced rule.

[0043] The above scheme stores decision records in a structured manner in a vector database, enabling constraint decisions to be retrieved, compared, and invoked by computers in the form of fields such as decision identifier, category, trigger type, semantic vector, contextual hints, and mandatory rules, thereby providing a data foundation for semantic similarity retrieval and subsequent review and judgment.

[0044] As one implementation, each decision record also includes a repair template field for storing code repair templates.

[0045] The above solution stores repair templates in the decision record, enabling the system to provide code repair references corresponding to the constraint decision when it identifies risks related to the constraint decision, thereby assisting in generating repair suggestions in the review results.

[0046] As one implementation, the method further includes: in response to the review result being blocked, generating a diagnostic object in the language server LSP protocol format, and sending the diagnostic object to the code editing environment for display; wherein the diagnostic object includes at least one of the following: a file path field for storing the path of the file to be alerted; a location range field for storing the start and end positions of the code to be alerted; a severity level field for characterizing the severity of the alert; an alert message field for storing the alert text content; and a repair suggestion field for storing code repair suggestions.

[0047] The above solution generates diagnostic objects in the LSP protocol format of the language server, enabling the review results to be recognized and displayed in the code editing environment, thereby directly presenting risk warnings, alarm locations, severity levels, alarm messages, and remediation suggestions to developers.

[0048] As one implementation, the repair suggestion field specifically includes: a repair title field, used to store the title text of the repair suggestion; and code editing instructions, used to specify the text replacement operation to be performed on the alarm file; the code editing instructions include: the start and end positions of the code to be replaced, and the new code text after replacement.

[0049] The above solution enables the code editing environment to perform targeted code replacement based on the start and end positions and replacement text by including the repair title and code editing instructions in the repair suggestion field, thereby achieving a connection between review alerts and code repair actions.

[0050] As one implementation, for code change events in multiple code files, multiple processes of the methods are executed in parallel using a thread pool, and an independent review context instance is allocated to each process; wherein, the review context instance is used to store the syntax tree structure, the set of nodes to be analyzed, and the set of affected code entities determined in the corresponding process.

[0051] The above solution uses a thread pool to process code change events of multiple code files in parallel and assigns an independent review context instance to each process, which can improve the review efficiency in multi-file code change scenarios, while avoiding mutual contamination of the syntax tree structure, the set of nodes to be analyzed, and the set of affected code entities of different files.

[0052] As one implementation, after determining the current review result, the method further includes: determining and caching review records based on the current review result, the current time, and the hash value of the syntax tree structure corresponding to the current code change text; before locating the syntax tree node corresponding to the code change location in the syntax tree structure, the method further includes: if the hash value of the syntax tree structure corresponding to the current code change text is determined to be the hash value in any review record in the cache, and the current time does not exceed a preset duration relative to the time in any review record; then the review result in any review record is taken as the current review result.

[0053] The above solution caches the review results, time, and syntax tree structure hash value, enabling the system to directly reuse existing review results when the syntax tree structure corresponding to the code change text has not changed substantially and the cache has not timed out, thereby reducing the computational overhead caused by repeated parsing, topological traversal, and semantic retrieval.

[0054] In summary, the code review method provided in this disclosure extracts the nodes to be analyzed from the syntax tree structure through the combined use of a decision memory and a code topology dependency graph. These nodes are then mapped to the code entities to be analyzed. A reverse traversal is performed to determine the set of affected code entities and calculate the impact range score. Simultaneously, semantic similarity retrieval is conducted based on code slices and constraint decisions to determine the decision matching score. Finally, the review result is determined based on the impact range score and the decision matching score. This solution can meet the technical requirements for comprehensive review of semantic constraint matching and topology impact range of code changes in scenarios involving continuous evolution of complex codebases and AI-assisted programming.

[0055] This disclosure provides a computer program product having at least one instruction stored thereon, which, when executed by a processor, implements any of the methods described above.

[0056] In addition, this disclosure also provides a code review system, including one or more program modules, which are used to implement the method described above.

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

[0058] In addition, this disclosure also provides a computer device, including: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and executed as described above.

[0059] This disclosure also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described above.

[0060] The beneficial effects of this disclosure include at least the following: by storing constraint decisions in a decision memory and determining the degree of matching between code slices and constraint decisions through semantic similarity retrieval, historical architectural decisions, prohibited patterns, or historical pitfall experiences can be transformed into machine-retrieval-based review criteria; by calculating the set of affected code entities and the scope of impact score through a code topology dependency graph, the propagation range of code changes in the dependency chain can be quantified; by fusing the scope of impact score and the decision matching score, more stable review results can be generated, and interception instructions or diagnostic objects can be output when the risk score exceeds a threshold. Attached Figure Description

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

[0062] Figure 1 This is the overall flowchart of the code review method;

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

[0064] 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.

[0065] Example 1: Overall Flow of Code Review Methods

[0066] This embodiment provides a computer-implemented code review method. This method can be implemented by a computer's processor loading and executing a computer program stored in memory. The computer can be deployed in a local development environment, a code review server, a continuous integration environment, a language server plugin, an IDE plugin, or the runtime environment where a code submission hook resides.

[0067] Before performing code reviews, a decision memory and a code topology dependency graph can be pre-built. The decision memory stores several constraint decisions, which may include design principles, prohibited patterns, historical pitfalls, interface constraints, state management constraints, and external system call constraints. The code topology dependency graph records the dependencies between code entities, where nodes represent code entities and directed edges represent calls, implementations, inheritance, or module-level dependencies between code entities.

[0068] When a code change event is detected, the processor responds to the event by obtaining the changed code text, the corresponding file path, the change location, and other information, and determines the syntax tree structure corresponding to the changed code text. For example, the processor can invoke a syntax parser to perform incremental parsing of the file containing the changed text, generating a subset of the syntax tree forest; this subset may include declaration nodes, expression nodes, statement nodes, identifier nodes, or literal nodes related to the current change.

[0069] After obtaining the syntax tree structure, the processor detects several syntax tree nodes of a specified type within the syntax tree structure to obtain a set of nodes to be analyzed. The specified type may include one or more of external interface calls, state modifications, and semantic identifiers. External interface calls can manifest as call expressions, member expressions, network requests, SDK interface calls, database access calls, or third-party service calls, etc.; state modifications can manifest as assignment expressions, update expressions, state writes, configuration writes, persistent storage, deletion, or committing state changes, etc.; semantic identifiers can manifest as identifiers with business meaning or architectural constraint meaning, such as identifiers related to permissions, payments, orders, state machines, user identifiers, external channels, resource quotas, or core interfaces.

[0070] For the set of nodes to be analyzed, the processor performs two main steps: First, it matches the set of code entities to be analyzed in the code topology dependency graph. Then, starting from each of these entities, it traverses backward along the dependencies to determine the set of affected code entities. Based on the scoring strategy associated with each affected entity, it obtains an impact range score. Second, the processor acquires the code slices corresponding to the set of nodes to be analyzed and performs semantic similarity retrieval in the decision memory. Based on the semantic similarity retrieval results, it determines a decision matching score. The processor then determines the review result based on the impact range score and the decision matching score.

[0071] In one example, the review results may include allow, alert, block, output of diagnostic objects, or output of remediation suggestions. If the impact scope score is high and the decision matching score indicates a high degree of match between the code slice and the constraint decision, the processor can generate a risk score and generate a block instruction if the risk score exceeds a preset threshold. If the impact scope score or decision matching score is low, the processor can generate an allow status code or a lower-level warning message.

[0072] Through the above process, the system does not need to rely solely on differences in code text or manual line-by-line review. Instead, it extracts semantically relevant nodes from the syntax tree structure and further combines the topological influence range and the degree of semantic matching in the decision to make a joint judgment.

[0073] Figure 1 This is the overall flowchart of the code review method. The process is triggered by a code change event. The system first obtains the code change text, file path, and change location, and determines the syntax tree structure corresponding to the code change text. Subsequently, the system detects syntax tree nodes of a specified type within the syntax tree structure, obtaining a set of nodes to be analyzed. The specified type includes one or more of external interface calls, state modifications, and semantic identifiers.

[0074] After obtaining the set of nodes to be analyzed, the process is divided into two analysis paths. The first path is the topological impact analysis path: the system matches the set of nodes to be analyzed in the code topological dependency graph to obtain the set of code entities to be analyzed, and then traverses backward along the dependency relationship starting from each code entity to determine the set of affected code entities. Finally, it obtains the impact range score based on the scoring strategy associated with the affected code entities. The second path is the semantic decision matching path: the system obtains the code slices corresponding to the set of nodes to be analyzed, performs semantic similarity retrieval in the decision memory, and determines the decision matching score based on the semantic similarity retrieval results.

[0075] Finally, the system integrates the impact scope score and the decision matching score to obtain a risk score, and determines whether the risk score exceeds a preset risk score threshold. If it exceeds the threshold, an interception instruction for the code change event is generated; if it does not exceed the threshold, a release status code or prompt message is generated, thereby outputting the review result.

[0076] Example 2: Construction of Decision Memory and Code Topology Dependency Graph

[0077] This embodiment illustrates the method of pre-constructing a decision memory and a code topology dependency graph.

[0078] In some implementations, the processor analyzes the codebase and extracts code entities. Code entities may include at least one of classes, interfaces, functions, and methods; in other implementations, code entities may also include program construction units with unique declaration paths, such as modules, namespaces, structures, enumerations, public variables, service objects, or configuration objects.

[0079] The processor assigns a globally qualified symbolic name as a unique identifier to each code entity. This globally qualified symbolic name can include the complete declaration path from the root namespace to the current code entity. For example, for a processing method in the payment module, a globally qualified symbolic name like "com.app.payment.PaymentService.processOrder" can be constructed. This globally qualified symbolic name distinguishes methods or classes with the same name in different files or scopes.

[0080] The processor identifies dependencies between code entities. These dependencies can include at least one of the following: call relationships, implementation relationships, inheritance relationships, and module-level dependencies. For example, if function A calls function B, a call edge pointing from function A to function B can be established in the code topology dependency graph; if class C implements interface I, an implementation edge pointing from class C to interface I can be established; if module M depends on module N, a module-level dependency edge pointing from module M to module N can be established. The processor constructs a code topology dependency graph in a graph database, using code entities as nodes and dependencies as directed edges.

[0081] In some implementations, each node in the code topology dependency graph is also associated with node attributes. The node identifier attribute stores the globally qualified symbolic name of the code entity; the entity type attribute represents the type of the code entity, such as class, interface, or method; and the decision binding attribute stores the decision identifier associated with the code entity, which points to a constraint decision in the decision memory. For example, an interface node can be bound to the constraint decision "all implementation classes must complete payment channel routing through the policy object," and a service node can be bound to the constraint decision "core permission status cannot be modified directly by bypassing the permission configuration table."

[0082] In some implementations, the decision memory may include a vector database. The decision memory stores several decision records, each of which may include a decision identifier field, a category field, a trigger type field, a semantic vector field, a context hint field, and a mandatory rule field. The decision identifier field stores a unique identifier for the constraint decision; the category field characterizes the type of constraint decision, such as design principle, prohibited mode, or historical pitfalls; the trigger type field stores the syntax tree node type that triggers the constraint decision; the semantic vector field stores the semantic vector representation of the constraint decision; the context hint field stores the rule description text for use by a large language model; and the mandatory rule field stores the text description of the enforced rule. Optionally, each decision record may also include a repair template field to store code repair templates.

[0083] The aforementioned decision memory and code topology dependency graph can be linked through decision identifiers. On one hand, nodes in the code topology dependency graph can point to decision records in the decision memory through decision binding attributes; on the other hand, the trigger type field and semantic vector field in the decision memory can be used for candidate filtering and similarity retrieval of the code slices corresponding to the nodes to be analyzed.

[0084] In the code topology dependency graph construction path, the system analyzes the code repository and extracts code entities, which include at least one of classes, interfaces, functions, and methods. Subsequently, the system assigns a globally qualified symbolic name as a unique identifier to each code entity, which includes the complete declaration path from the root namespace to the current code entity. The system further identifies the dependencies between code entities, including at least one of call relationships, implementation relationships, inheritance relationships, and module-level dependencies. Using code entities as nodes and dependencies as directed edges, the system constructs a code topology dependency graph in the graph database.

[0085] In the code topology dependency graph, each node can also be associated with node attributes. The node identifier attribute is used to store the globally qualified symbolic name of the code entity; the entity type attribute is used to represent the type of the code entity, such as class, interface, or method; and the decision binding attribute is used to store the decision identifier associated with the code entity, which points to the constraint decision in the decision memory.

[0086] In the decision memory construction path, the system creates several decision records. Each decision record may include a decision identifier field, a category field, a trigger type field, a semantic vector field, a context hint field, and a mandatory rule field; optionally, each decision record may also include a repair template field. Through the decision identifier, code entity nodes in the code topology dependency graph can be associated with constraint decisions in the decision memory, thereby supporting subsequent joint review based on topological entities and semantic similarity.

[0087] Example 3: Syntax Tree Parsing and Extraction of the Set of Nodes to be Analyzed

[0088] This embodiment describes how to determine the syntax tree structure and extract the set of nodes to be analyzed in response to code change events.

[0089] In some implementations, code change events can originate from IDE buffer modification events, Git commit events, code merge request events, continuous integration pipeline trigger events, or difference text commit events in the code review platform. The processor receives the code change text, file path, and code change location, and performs syntax tree parsing based on the code change location and the file path of the code change text to obtain a subset of the syntax tree forest, which serves as the syntax tree structure corresponding to the code change text.

[0090] A subset of the syntax tree forest can preserve the hierarchical relationships between nodes related to the location of changes. For example, for a piece of external interface call code, the syntax tree forest subset may include call expression nodes, member expression nodes, identifier nodes, parameter expression nodes, and their ancestor method declaration nodes or class declaration nodes. For a piece of state modification code, the syntax tree forest subset may include assignment expression nodes, lvalue identifier nodes, rvalue expression nodes, and their corresponding statement nodes. Preserving the parent-child relationships between nodes helps with subsequent code slice extraction, symbol resolution, and the construction of globally qualified symbol names.

[0091] The processor detects several syntax tree nodes of the specified type in the syntax tree structure to obtain a set of nodes to be analyzed. The specified type can be pre-configured according to the review requirements, or it can be dynamically generated based on the trigger type field of the constraint decision in the decision memory. For example, the specified type includes one of external interface calls, state modifications, and semantic identifiers.

[0092] For external interface calls, the processor can identify call expressions or member expressions and determine whether the call points to a service, SDK, database access layer, remote interface, or public framework interface outside the current module. For state modifications, the processor can identify assignment expressions, update expressions, object property writes, collection writes, state commit function calls, or persistence save calls. For semantic identifiers, the processor can identify identifiers that appear near the code change location and have business or architectural constraint meanings, such as names related to user permissions, payment channels, order status, risk control status, concurrency locks, resource quotas, and external system identifiers.

[0093] In some implementations, the set of nodes to be analyzed may include information such as the node type, source code slice, file path, start and end positions, parent node index, child node index, belonging declaration node, and extracted symbol names for each node. This information can be used for subsequent topology matching, semantic vectorization, and diagnostic object generation.

[0094] The syntax tree forest subset preserves the hierarchical relationships of nodes related to the location of changes. For example, for external interface call code, the syntax tree forest subset may include call expression nodes, member expression nodes, identifier nodes, parameter expression nodes, and their ancestor method declaration nodes or class declaration nodes; for state modification code, the syntax tree forest subset may include assignment expression nodes, lvalue identifier nodes, rvalue expression nodes, and their corresponding statement nodes. Preserving the parent-child relationships between nodes helps in subsequent code slice extraction, symbol resolution, and the construction of globally qualified symbol names.

[0095] After obtaining the syntax tree structure, the system detects syntax tree nodes of the specified type. For external interface calls, the system identifies the call expression or member expression and determines whether the call points to a service, SDK, database access layer, remote interface, or public framework interface outside the current module. For state modifications, the system identifies assignment expressions, update expressions, object property writes, collection writes, state commit function calls, or persistent save calls. For semantic identifiers, the system identifies identifiers that appear near the code change location and have business or architectural constraint meanings, such as names related to user permissions, payment channels, order status, risk control status, concurrency locks, resource quotas, or external system identifiers.

[0096] If a syntax tree node belongs to a specified type, the system will form it into a node to be analyzed and record information such as node type, source code slice, file path, start and end positions, parent node index, child node index, belonging declaration node, and extracted symbol name. If a syntax tree node does not belong to a specified type, the node will be discarded or skipped, and the system will continue processing the next syntax tree node. Finally, the system will output a set of nodes to be analyzed, which will be used for subsequent topology matching, semantic vectorization, and diagnostic object generation.

[0097] Example 4: Mapping from the node to be analyzed to the code entity to be analyzed

[0098] This embodiment describes how to obtain the set of code entities to be analyzed by matching the set of nodes to be analyzed in the code topology dependency graph.

[0099] For each node in the set of nodes to be analyzed, the processor parses the complete declaration path from the root node to the node to be analyzed from the syntax tree, obtains the globally qualified symbol name corresponding to the node to be analyzed, and matches the corresponding code entity to be analyzed in the code topology dependency graph based on the globally qualified symbol name.

[0100] In some implementations, the processor first identifies the node type of the node to be analyzed. If the node to be analyzed is a declaration node, such as a class declaration node, interface declaration node, function declaration node, or method declaration node, the processor can directly construct a globally qualified symbolic name based on the declaration path. For example, if the current node is a processOrder method declaration under the PaymentService class, a globally qualified symbolic name can be constructed based on the namespace, module name, class name, and method name.

[0101] If the node to be analyzed is a user node, the processor determines the external entity referenced by the user node through symbol resolution. User nodes can include identifier nodes or expression nodes. For example, if the node to be analyzed is an identifier in a member expression, the processor can determine the declaration location of the identifier reference through the scope chain, import statements, type information, or the language server symbol table.

[0102] For a usage node, the processor can determine whether the external entity is a parameter, local variable, or current class member. If the usage node references a method parameter, local variable, or current class member, the usage node can be overridden by the globally qualified symbolic name of the current method or class, and does not necessarily need to construct a separate globally qualified symbolic name. If the usage node references an imported external class, external function, external method, external service object, or external interface, the processor constructs a globally qualified symbolic name based on the declaration path of the external entity and queries the corresponding node in the code topology dependency graph.

[0103] In some implementations, the same node to be analyzed can be mapped to one or more code entities to be analyzed. For example, an external interface call node can be mapped to the method entity where the current call takes place, or it can be mapped to the called external interface entity; a state modification node can be mapped to the current method entity, or it can be mapped to the class entity corresponding to the modified state object. The processor can merge the code entities mapped from multiple nodes to be analyzed and remove duplicate entities to form a set of code entities to be analyzed.

[0104] Example 5: Reverse Traversal and Influence Range Scoring

[0105] This embodiment describes the method for determining the set of affected code entities and calculating the impact range score based on the code topology dependency graph.

[0106] In a code topology dependency graph, directed edges represent dependencies between code entities. If code entity A calls code entity B, then A can be considered dependent on B; when B changes, A may be affected. Therefore, when assessing the scope of the impact of code changes, we can start with the code entity to be analyzed and traverse in the reverse direction of the dependencies to find the upstream code entities that call or depend on the code entity to be analyzed.

[0107] For each code entity to be analyzed, the processor adds it to the traversal queue, initializes the current traversal depth to zero, and establishes a visit set. The processor retrieves the current node from the traversal queue, queries the code topology dependency graph for directed edges ending at the current node, and obtains the starting node of the directed edge as the upstream node. For upstream nodes that have not yet been visited, the processor adds them to the affected code entity set and records the number of hops from the starting traversal of the analyzed code entity; then, it adds the upstream node to the traversal queue and increments the traversal depth. This process can be repeated until the traversal depth reaches a preset maximum depth or the traversal queue is empty.

[0108] In some implementations, the preset maximum depth can be configured based on project size, module structure, or review latency requirements. For example, in large codebases, the maximum depth can be set to 3, 5, or other appropriate values ​​to avoid excessive traversal leading to increased computational costs. Access sets can be used to avoid repeatedly traversing the same node or causing infinite loops when circular dependencies exist.

[0109] After determining the set of affected code entities, the processor determines the entity weights based on the types of the affected code entities. For example, the weight of an interface type can be higher than that of a class type, and the weight of a class type can be higher than that of a method type. This is because an interface typically represents an architectural contract that multiple implementing classes follow; a class typically represents an encapsulation of a set of states and behaviors; and a method typically represents a concrete implementation unit. Optionally, entity weights can also be adjusted based on factors such as whether it is a public interface, whether it is exported, whether it belongs to a core module, and whether it is bound to key constraint decisions.

[0110] For each affected code entity, the processor calculates its influence range score based on its entity weight and its hierarchical distance relative to the initially traversed code entity to be analyzed. The influence range score is positively correlated with the entity weight and negatively correlated with the hierarchical distance. For example, it can be calculated using the formula P_i = w_i·γ^{d_i}, where P_i represents the influence range score for the i-th affected code entity, w_i represents the entity weight, d_i represents the hierarchical distance, and γ represents the propagation attenuation factor, where γ < 1.

[0111] After obtaining the impact range scores for each affected code entity, the processor can fuse and normalize the impact range scores corresponding to all affected code entities. For example, the processor can first calculate P_total=sum_{i∈V_affected}(w_i·γ^{d_i}), and then calculate D_impact=1−exp(−λ·P_total) to obtain the normalized impact range scores. The above normalization calculation can transform the unbounded cumulative value into a finite interval, making it easier to fuse with the decision matching score.

[0112] Example 6: Semantic Similarity Retrieval in Decision Memory

[0113] This embodiment describes how to perform semantic similarity retrieval in the decision memory and determine the decision matching score based on the code slices corresponding to the set of nodes to be analyzed.

[0114] The processor can extract a corresponding code slice for each node in the set of nodes to be analyzed. The code slice can include the source code fragment corresponding to the node itself, or a portion of the context from its parent node, child nodes, associated statements, method signatures, related import statements, or related comments. The length of the code slice can be configured according to the input constraints of the vectorized model, retrieval accuracy, and review latency requirements.

[0115] In some implementations, the decision memory includes a trigger type associated with each constraint decision, which is the syntax tree node type that triggers the constraint decision. The processor can match the type of each node to be analyzed with the trigger type associated with each constraint decision in the decision memory, filtering out constraint decisions associated with trigger types that match the type of any node to be analyzed, forming a target constraint decision set. For example, if the node to be analyzed belongs to the external interface call type, constraint decisions related to external interface calls, remote service dependencies, database access, or SDK calls can be prioritized; if the node to be analyzed belongs to the state modification type, constraint decisions related to state consistency, permission state, order state, cache state, or configuration state can be prioritized.

[0116] In some implementations, before performing semantic similarity retrieval in the target constraint decision set based on the code slice corresponding to each node to be analyzed, the processor may also add the constraint decisions associated with at least some of the code entities to be analyzed and / or at least some of the affected code entities to the target constraint decision set. This approach can introduce decision binding attributes from the code topology dependency graph into the semantic retrieval candidate pool. For example, if the code entity to be analyzed is an implementation class of a core interface, and the core interface node is bound to several constraint decisions, these constraint decisions can be added to the target constraint decision set for subsequent similarity retrieval.

[0117] In some implementations, the decision memory also includes a decision semantic vector associated with each constraint decision. The processor converts the code slice corresponding to each node to be analyzed into a code semantic vector and calculates the similarity between each code semantic vector and each decision semantic vector in the target constraint decision set. The similarity can be cosine similarity, similarity after Euclidean distance transformation, or other vector similarity metrics.

[0118] For example, if the code semantic vector is represented as V_code and the decision semantic vector is represented as V_rule_i, then the cosine similarity can be expressed as:

[0119] Sim(V_code,V_rule_i)=(V_code·V_rule_i) / (||V_code||_2·||V_rule_i||_2).

[0120] The processor can sort the combinations of code slices and constraint decisions from highest to lowest similarity and extract the maximum similarity or Top-K similarity results.

[0121] In one implementation, in response to a maximum similarity score exceeding a preset similarity threshold, the processor determines the combination of the code slice and constraint decision corresponding to the maximum similarity score, and invokes a large model to analyze the matching performance of the code slice and constraint decision within this combination. The large model can receive the code slice, the contextual hint field of the constraint decision, and the mandatory rule field, and output the analysis results characterizing the matching performance. The processor determines a decision matching score based on the model analysis results. For example, if the model analysis results indicate that the code slice violates the constraint decision with a high confidence level, the decision matching score can be set to a higher value; if the model analysis results indicate that the code slice does not violate the constraint decision, the decision matching score can be set to a lower value or zero.

[0122] In another implementation, if the maximum similarity does not exceed a preset similarity threshold, the processor may not invoke the large model, but instead determine a lower decision matching score based on the similarity results, or set the decision matching score to zero. This approach reduces model invocation costs while preserving the contribution of semantic retrieval to the review results.

[0123] Example 7: Generation of Review Results and Display of LSP Diagnostic Objects

[0124] This embodiment explains how to determine the review results based on the impact range score and the decision matching score.

[0125] The processor can perform a weighted fusion calculation of the impact range score and the decision matching score to obtain a risk score. For example, the risk score can be expressed as:

[0126] R_score=W_graph·D_impact+W_decision·D_decision;

[0127] Where D_impact represents the impact scope score, D_decision represents the decision matching score, W_graph represents the impact scope weight, and W_decision represents the decision matching weight. W_graph and W_decision can be configured according to the project review strategy, or adjusted according to the code repository type, module importance, code review stage, or historical false positives.

[0128] When the risk score exceeds a preset risk score threshold, the processor generates an interception instruction for the code change event. This interception instruction can be used to block commits, block merges, block continuous integration processes, or require developers to process relevant diagnostic information and resubmit. When the risk score does not exceed the preset risk score threshold, the processor can generate a release status code or generate an alert without blocking the code change.

[0129] In some implementations, in response to a blocked review result, the processor generates a diagnostic object in the language server LSP protocol format and sends the diagnostic object to the code editing environment for display. The diagnostic object may include at least one of the following: file path field, location range field, severity level field, alarm message field, and repair suggestion field.

[0130] The file path field stores the path to the file to be alerted. The location range field stores the start and end positions of the code to be alerted; this position can be derived from the line and column numbers or byte offsets of the code slice corresponding to the node to be analyzed within the file. The severity level field characterizes the severity of the alert, such as error, warning, or alert. The alert message field stores the alert text content, which may include the matched constraint decisions, decision matching scores, impact range scores, related affected code entities, or suggested handling methods. The remediation suggestion field stores code remediation suggestions.

[0131] Furthermore, the repair suggestion field may include a repair title field and code editing instructions. The repair title field stores the title text of the repair suggestion; the code editing instructions specify the text replacement operation to be performed on the alarm file, and the code editing instructions may include the start and end positions of the code to be replaced and the new code text after replacement. The new code text after replacement may come from the repair template field of the decision record in the decision memory, or from the model analysis results or pre-configured rule templates.

[0132] In this way, the review results can not only generate risk scores on the server side, but also be converted into IDE diagnostic information that developers can perceive and act upon.

[0133] Example 8: Parallel Processing and Caching

[0134] This embodiment describes the parallel processing and caching methods in scenarios involving multiple file code changes.

[0135] In some implementations, code change events can involve multiple code files simultaneously. The processor can use a thread pool to execute multiple code review processes in parallel, assigning an independent review context instance to each process. Each review context instance can be used to store the syntax tree structure determined in the corresponding process, the set of nodes to be analyzed, the set of code entities to be analyzed, the set of affected code entities, the impact scope score, the target constraint decision set, the decision matching score, and the final review result. Using independent context instances can reduce state conflicts between different file review processes and improve processing efficiency in multi-file change scenarios.

[0136] In some implementations, after determining the current review result, the processor determines and caches the review record based on the current review result, the current time, and the hash value of the syntax tree structure corresponding to the current code change text. The hash value of the syntax tree structure can be calculated from a subset of the syntax tree forest, the set of nodes to be analyzed, code slices, or related structured fields.

[0137] In subsequent reviews, before locating the syntax tree node corresponding to the code change location in the syntax tree structure, the processor can determine whether the hash value of the syntax tree structure corresponding to the current code change text is the same as the hash value in any review record in the cache, and whether the current time relative to the time in that review record has not exceeded a preset duration. If the above conditions are met, the processor can use the review result in that review record as the current review result, thereby reducing repeated parsing, topological traversal, and semantic similarity retrieval.

[0138] Example 9: Review of External Interface Call Changes

[0139] This embodiment provides a runtime example of an external interface call change. The developer adds a piece of external payment channel call logic to the code, for example, directly calling the `charge` interface of a third-party payment SDK in the order processing method. In response to the code change event, the processor parses the syntax tree forest subset related to the changed location and identifies the node to be analyzed within it, representing the type of external interface call.

[0140] The processor performs symbol resolution on the calling node to determine the external SDK interface referenced by the calling node, and constructs the declaration path of the external interface into a globally qualified symbol name. The processor matches the external interface entity and the current order processing method entity in the code topology dependency graph, and adds them to the set of code entities to be analyzed.

[0141] The processor performs a reverse traversal starting from the code entity to be analyzed, querying the upstream nodes that call or depend on that entity to obtain the set of affected code entities. For example, the set of affected code entities may include order services, payment services, refund services, accounting and settlement modules, or external API interface layers. The processor calculates the scope of impact score based on entity type and hierarchical distance.

[0142] Simultaneously, the processor extracts the code slice corresponding to the external interface call, converts it into a code semantic vector, and retrieves the constraint decisions related to the external interface call from the decision memory. If the constraint decision "the core payment process must access the third-party channel through the payment strategy interface or unified gateway" is matched, and the similarity exceeds a preset threshold, the processor can further call a large model to analyze the matching between the code slice and the constraint decision, and determine the decision matching score based on the model analysis results. The processor finally merges the impact range score and the decision matching score. If the risk score exceeds the threshold, an interception instruction and an LSP diagnostic object are generated.

[0143] Example 10: Review of Status Modification / Change

[0144] This embodiment provides a runtime example of state modification. The developer adds direct write logic to the user's permission state in the permission handling code. The processor responds to the code change event, parses the syntax tree structure, and identifies the nodes to be analyzed based on the state modification type, such as assignment expression nodes, object property write nodes, or state commit function call nodes.

[0145] The processor constructs the globally qualified symbolic name of the current method or class based on the declaration path of the modified state node, and determines whether the modified state object belongs to an external entity or a member of the current class through symbol resolution. If the modified state object corresponds to a shared state class or permission state interface, the processor can match the corresponding code entity in the code topology dependency graph.

[0146] The processor performs a reverse traversal starting from the code entity to determine the upstream modules that depend on the state entity, such as the permission verification module, audit module, business service module, or interface layer module, and calculates the scope of influence score based on the entity weight and hierarchical distance.

[0147] The processor extracts code slices related to state modification, filters constraint decisions related to state modification in the decision memory, and performs semantic similarity retrieval. If a code slice has a high similarity to the constraint decision "Permission state modification must be executed through unified permission configuration or state machine interface," the processor determines a decision matching score based on the similarity and model analysis results. Finally, the processor generates a review result based on the impact scope score and the decision matching score. If the review result is an interception, an alert message can be displayed in the code editing environment, along with a remedial suggestion to replace direct state writing with a unified state interface call.

[0148] Example 11: Review of Semantic Identifier Changes

[0149] This embodiment provides a runtime example of semantic identifier modification. The developer adds or modifies identifiers related to order status, user identification, or resource quotas in the code. The processor identifies the node to be analyzed in the syntax tree structure based on the semantic identifier type and extracts code slices by combining the expression, statement, method declaration, and class declaration containing that identifier.

[0150] The processor performs symbol resolution on semantic identifiers to determine whether they reference external entities. If the semantic identifier references a parameter or local variable, the processor can classify it into the current method entity; if the semantic identifier references an external state class, external interface, or imported module, the processor constructs the globally qualified symbolic name of the external entity and matches the corresponding code entity in the code topology dependency graph.

[0151] The processor performs a reverse dependency traversal based on the matched code entities to obtain the set of affected code entities and calculates the impact scope score. Simultaneously, the processor converts the code slice containing the semantic identifier into a code semantic vector and retrieves constraint decisions with similar semantics from the decision memory. If the search results indicate that the identifier change may affect existing architectural decisions or historical pitfall rules, the processor determines the corresponding decision matching score. The processor determines the final review result based on the impact scope score and the decision matching score.

[0152] 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.

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

[0154] 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.

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

[0156] 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.

[0157] 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 technical scope 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 by, A decision memory and a code topology dependency graph are pre-constructed. The decision memory stores several constraint decisions. The nodes in the code topology dependency graph represent code entities. Each code entity is a program construction unit with a unique declared path. The directed edges in the code topology dependency graph represent the dependency relationships between code entities. The computer includes a memory and a processor, the memory storing a computer program adapted to be loaded by the processor and executed in the method, the method comprising: In response to code change events, determine the syntax tree structure corresponding to the code change text; Detecting several syntax tree nodes of a specified type in the syntax tree structure yields a set of nodes to be analyzed; wherein, the specified type includes one of external interface calls, state modifications, and semantic identifiers; Based on the set of nodes to be analyzed, a set of code entities to be analyzed is obtained by matching in the code topology dependency graph. In the code topology dependency graph, starting from each code entity to be analyzed, the traversal is performed in reverse along the dependency relationship to determine the set of affected code entities. And based on the scoring strategy associated with each affected code entity, the scope of influence score is obtained. Based on the code slices corresponding to the set of nodes to be analyzed, semantic similarity retrieval is performed in the decision memory; and based on the semantic similarity retrieval results, a decision matching score is determined. The review result is determined based on the impact range score and the decision matching score.

2. The method according to claim 1, characterized in that, The code topology dependency graph is constructed in the following ways: The codebase is analyzed to extract code entities, which include at least one of classes, interfaces, functions, and methods. Each code entity is assigned a globally qualified symbol name as a unique identifier, the globally qualified symbol name including the complete declaration path from the root namespace to the current code entity; Identify dependencies between code entities, including at least one of call relationships, implementation relationships, inheritance relationships, and module-level dependencies; Using code entities as nodes and dependencies as directed edges, construct a code topology dependency graph in a graph database; Each node in the code topology dependency graph is also associated with node attributes, which include at least the following: The node identifier attribute is used to store the globally qualified symbol name of the code entity; The entity type attribute is used to characterize the type of the code entity, which includes class, interface, and method; The decision binding attribute stores a decision identifier associated with the code entity, which points to a constraint decision in the decision memory.

3. The method according to claim 1, characterized in that, Based on the set of nodes to be analyzed, a set of code entities to be analyzed is obtained by matching them in the code topology dependency graph, specifically including: For each node to be analyzed in the set of nodes to be analyzed, the complete declaration path from the root node to the node to be analyzed is parsed from the syntax tree to obtain the global qualified symbol name corresponding to the node to be analyzed. Based on the globally qualified symbol name corresponding to the node to be analyzed, the corresponding code entity to be analyzed is obtained by matching in the code topology dependency graph; For each dangerous node in the set of dangerous nodes, the complete declaration path from the root node to the node to be analyzed is parsed from the syntax tree, including: Identify the node type of the node to be analyzed; In response that the node to be analyzed is a declaration node, a globally qualified symbol name is constructed based on the declaration path; In response to the node to be analyzed being a usage node, the external entity referenced by the usage node is determined through symbol resolution; the usage node includes an identifier node or an expression node; If the external entity is not a parameter, local variable, or current class member, a globally qualified symbol name is constructed based on the declaration path of the external entity.

4. The method according to claim 1, characterized in that, In the code topology dependency graph, starting from each code entity to be analyzed, a reverse traversal is performed along the dependency relationships to determine the set of affected code entities, including: For each code entity to be analyzed, add the code entity to the traversal queue and initialize the current traversal depth to zero; Take the current node from the traversal queue, query the directed edge with the current node as the endpoint in the code topology dependency graph, and obtain the starting node of the directed edge as the upstream node. Add unvisited upstream nodes to the set of affected code entities and record the number of hops between the upstream node and the code entity to be analyzed; Add the upstream node to the traversal queue, increment the traversal depth, and repeat the traversal until the traversal depth reaches the preset maximum depth or the traversal queue is empty. The process of obtaining an impact range score based on the scoring strategy associated with each affected code entity includes: The entity weight is determined based on the type of the affected code entity, with interface types having a higher weight than class types, and class types having a higher weight than method types. For each affected code entity, the influence range score is calculated based on the entity weight of the affected code entity and the hierarchical distance of the affected code entity relative to the initially traversed code entity to be analyzed. The influence range score is positively correlated with the entity weight and negatively correlated with the hierarchical distance. The step of obtaining the impact range score based on the scoring strategy associated with each affected code entity also includes the following steps: The impact range scores corresponding to all affected code entities are merged and normalized to obtain the impact range score corresponding to the set of affected code entities.

5. The method according to claim 1, characterized in that, The review results are determined based on the impact range score and the decision matching score, specifically including: The risk score is obtained by weighted and fused together the impact range score and the decision matching score. In response to the risk score exceeding a preset risk score threshold, an interception instruction is generated for the code change event.

6. The method according to claim 1, characterized in that, The decision memory also includes a trigger type associated with each constraint decision, which is the syntax tree node type that triggers the constraint decision; Based on the code slices corresponding to the set of nodes to be analyzed, semantic similarity retrieval is performed in the decision memory, specifically including: The type of each node to be analyzed is matched with the trigger type associated with each constraint decision in the decision memory, and the constraint decisions associated with the trigger types that match the type of any node to be analyzed are filtered out to form a set of target constraint decisions; Based on the code slice corresponding to each node to be analyzed, semantic similarity retrieval is performed in the target constraint decision set.

7. The method according to claim 6, characterized in that, The decision memory also includes a decision identifier associated with each constraint decision; the code entities in the code topology dependency graph are associated with decision identifiers; Before performing semantic similarity retrieval in the target constraint decision set based on the code slice corresponding to each node to be analyzed, the method further includes: adding the constraint decisions associated with at least some of the code entities to be analyzed and / or at least some of the affected code entities to the target constraint decision set; or The decision memory also includes a decision semantic vector associated with each constraint decision; based on the code slice corresponding to each node to be analyzed, semantic similarity retrieval is performed in the target constraint decision set, specifically including: converting the code slice corresponding to each node to be analyzed into a code semantic vector; calculating the similarity between the code semantic vector corresponding to each node to be analyzed and each decision semantic vector in the target constraint decision set; determining a decision matching score based on the semantic similarity retrieval results, specifically including: sorting the combinations of code slices and constraint decisions from largest to smallest similarity; in response to the maximum similarity being greater than a preset similarity threshold, determining the combination of code slices and constraint decisions corresponding to the maximum similarity, and calling a large model to analyze the matching of code slices and constraint decisions within this combination; determining a decision matching score based on the model analysis results.

8. The method according to claim 1, characterized in that, The decision memory includes a vector database, which stores several decision records. Each decision record includes the following fields: The decision identifier field is used to store a unique identifier for constraint decisions; The category field is used to characterize the type of constraint decision, which includes at least one of design principles, prohibited modes, and historical pitfalls. The trigger type field stores the type of the syntax tree node that triggers the constraint decision; The semantic vector field is used to store the semantic vector representation of the constraint decision, and the semantic vector is used for semantic similarity retrieval; The context hint field is used to store rule description text for use by large language models; The "Enforcement Rule" field stores the text description of the rule that must be enforced. Each decision record also includes a repair template field, which stores code repair templates.

9. The method according to claim 1, characterized in that, The method further includes: In response to the review result being blocked, a diagnostic object in the language server LSP protocol format is generated. The diagnostic object is sent to the code editing environment for display; The diagnostic object includes at least one of the following: The file path field is used to store the path of the file to be alerted. The location range field is used to store the start and end locations of the alarm code to be triggered; The severity level field is used to characterize the severity of the alarm; The alarm message field is used to store the alarm text content; The "Repair Suggestions" field is used to store code repair suggestions; The repair suggestion field specifically includes: The repair title field stores the title text of the repair suggestion; The code editing instructions are used to specify the text replacement operation to be performed on the alarm file; the code editing instructions include: the start and end positions of the code to be replaced, and the new code text after replacement.

10. The method according to claim 1, characterized in that, in, For code change events in multiple code files, a thread pool is used to execute multiple of the methods in parallel, and an independent review context instance is assigned to each process. The review context instance is used to store the syntax tree structure, dangerous node set, and affected code entity set determined in the corresponding process.

11. The method according to claim 1, characterized in that, After determining the current review outcome, the method further includes: Based on the current review results, the current time, and the hash value of the syntax tree structure corresponding to the current code change text, the review record is determined and cached. Before locating the syntax tree node corresponding to the code change location in the syntax tree structure, the method further includes: If it is determined that the hash value of the syntax tree structure corresponding to the current code change text is the hash value of any review record in the cache, and the current time does not exceed the preset duration relative to the time in any review record; Then the review result in any of the review records will be used as the current review result.

12. 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-11.

Images