A code comparison report automatic generation method, system, device and medium

Abstract

The application is suitable for the technical field of software development, and provides a code comparison report automatic generation method, which comprises the following steps: receiving path information and comparison configuration information input by a user through a command line interface; calling a command line program of an external comparison tool in combination with the path information and the comparison configuration information; triggering a code comparison process and a report generation process through the command line program to generate a comparison report file; the application calls the external comparison tool through the command line program in a silent mode, improves the code comparison efficiency, simultaneously realizes automatic scheduling of the external comparison tool, and further understands code changes from a semantic level, semantizes analysis results of the external comparison tool, generates intermediate data, and finally integrates the intermediate data into the comparison report file.

Description

Technical Field

[0001] This application relates to the field of software development technology, and in particular to a method, system, device, and medium for automatically generating code comparison reports. Background Technology

[0002] In software development, code comparison is a core part of version control, code review, and merging. Existing technologies, such as Beyond Compare, provide powerful comparison functions. However, when using Beyond Compare for code comparison, users usually need to manually perform a series of graphical interface operations, such as starting the software, selecting the two files or folders to be compared in the interface, performing the comparison operation, and manually exporting or viewing the comparison report.

[0003] The aforementioned operation mode, which relies on a graphical user interface, is inefficient when handling a large number of frequent code comparison tasks. Especially in complex project environments, developers may need to repeatedly compare different versions and branches of code. The repetitiveness and tediousness of manual operations greatly increase the workload and become a bottleneck affecting development efficiency. Summary of the Invention

[0004] This application provides a method, system, device, and medium for automatically generating code comparison reports, which can solve one of the problems of the prior art mentioned above.

[0005] In a first aspect, embodiments of this application provide a method for automatically generating a code comparison report, including: Receive path information and comparison configuration information input by the user through the command-line interface; Combining the path information and the comparison configuration information, the command-line program of an external comparison tool is invoked; The command-line program triggers the code comparison process and report generation process, generating a comparison report file.

[0006] Furthermore, the step of receiving user-inputted path information and comparison configuration information via the command-line interface includes: The system captures the raw parameter vector of the command line input and uses a command line parameter parsing library to perform structured parsing and verification of the raw parameter vector, generating path information and comparison configuration information. The path information includes a first code path, a second code path, and a report output path.

[0007] Furthermore, the step of combining the path information and the comparison configuration information to invoke the command-line program of an external comparison tool includes: Load the static configuration file, prioritize and merge the static configuration file with the comparison configuration information, and generate the runtime configuration; Based on the runtime configuration, generate an executable configuration script file for the external comparison tool; Based on a predefined command template, combined with the external comparison tool and configuration script file, command line instructions are generated; The command-line instructions are executed in silent mode by creating a child process.

[0008] Furthermore, the command template includes silent execution parameters, configuration script parameters, and path information. The silent execution parameters are the parameters used by the external comparison tool when executing the command in silent mode, and the configuration script parameters are the absolute path of the configuration script file.

[0009] Furthermore, the step of triggering the code comparison process and report generation process through the command-line program to generate a comparison report file includes: The source code files corresponding to the first code path and the second code path are respectively parsed into a first abstract syntax tree and a second abstract syntax tree; The first abstract syntax tree and the second abstract syntax tree are compared by a tree matching algorithm to identify semantic-level changes, and semantic tags are marked for the semantic-level changes according to a predefined rule base. The semantic-level changes and semantic tags are serialized into intermediate data, and the intermediate data is integrated to generate a comparison report file through the configuration script file.

[0010] Furthermore, the step of comparing the first abstract syntax tree and the second abstract syntax tree using a tree matching algorithm to identify semantic-level changes, and labeling the semantic-level changes with semantic tags according to a predefined rule base, includes: In the first abstract syntax tree and the second abstract syntax tree, each node represents a structural element in the code; Calculate node feature values ​​for each node based on its attributes; By combining the node feature values, multi-level node matching is performed to construct matching relationships between the nodes of the first abstract syntax tree and the second abstract syntax tree; Based on the rule engine, semantic analysis is performed on the matching relationships of each node to generate semantic tags.

[0011] Furthermore, the process of performing semantic analysis on the matching relationships of each node based on the rule engine and generating semantic tags includes: In the rule engine, a fact object model is constructed, which is used to describe changes between nodes with matching relationships; Based on the Rete algorithm, the changed node facts are updated and matched to generate changed semantic labels, and the confidence of each semantic label is calculated. Output a set of semantic tags, each carrying a confidence level, and describe the semantic meaning of the code change through each semantic tag.

[0012] Secondly, embodiments of this application provide an automatic code comparison report generation system, including: The first processing module is used to receive path information and compare configuration information input by the user through the command line interface. The second processing module is a command-line program used to combine the path information and the comparison configuration information to call an external comparison tool. The third processing module is used to trigger the code comparison process and report generation process through the command-line program, and generate a comparison report file.

[0013] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described automatic code comparison report generation method.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium, including a computer program stored in the computer-readable storage medium, wherein the computer program, when executed by a processor, implements the above-described method for automatically generating a code comparison report.

[0015] The beneficial effects of the embodiments in this application compared with the prior art are: This application discloses a method for automatically generating code comparison reports. It receives user input via a command-line interface and transforms it into a command-line program for calling external comparison tools. The external comparison tools are invoked silently via the command-line program, improving the efficiency of code comparison. Simultaneously, it automates the scheduling of external comparison tools. Furthermore, it understands code changes at a semantic level, semantically interprets the analysis results of external comparison tools, generates intermediate data, and finally integrates it into a comparison report file. The report's format, content, and level of detail can be customized according to user needs to meet the requirements of different scenarios. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating an automatic code comparison report generation method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of an automatic code comparison report generation system provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0018] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0019] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0020] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0021] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0022] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0023] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0024] Please see Figure 1 As shown, this invention is a method for automatically generating code comparison reports, comprising the following steps: S100: Receives path information and comparison configuration information input by the user through the command line interface; In some embodiments, step S100 above includes: The system captures the raw parameter vector of the command line input and uses a command line parameter parsing library to perform structured parsing and verification of the raw parameter vector, generating path information and comparison configuration information. The path information includes a first code path, a second code path, and a report output path.

[0025] In this embodiment, a command line is constructed to input the parameters required by the user when performing code comparison, namely the original vector parameters. The original vector parameters typically include required parameters and optional parameters. The required parameters include parameters for the first code path, the second code path, and the report output path. Optional parameters include comparison configuration information, etc. Specifically, the first code path and the second code path are the storage paths of the two codes to be compared, while the report output path is the storage path when the comparison report file is generated, which facilitates the subsequent retrieval of the comparison report file. Furthermore, the comparison configuration information is the configuration information set by the external comparison tool according to the actual running scenario and requirements when performing code comparison. It is temporary and flexible and is an optional parameter. It is combined with the static configuration file of the external comparison tool to guide the behavior of the external comparison tool throughout the entire operation.

[0026] Specifically, the command-line interface defines the parameter rules for each parameter in the user-input raw parameter vector. Parameter types include positional parameters and option parameters, and each parameter type is configured with parameter metadata to facilitate subsequent parsing of the raw parameter vector. Specifically, positional parameters are parameters identified by their order, such as `node script.js`. <source-path> <target-path> <output-path>In the original parameter vector mentioned above, <source-path> 、 <target-path>as well as <output-path>These are the positional parameters identified sequentially by the user during input, where... <source-path>The first code path represents the source code path. <target-path>The second code path represents the target code path to be compared. <output-path>The output path is specified to indicate the final output path. As you can understand, positional parameters are required and set according to their location in the command-line interface, while option parameters are identified by name, such as the configuration script parameter `--config` indicating the path to the configuration script file. <file-path>The parameter type is identified by "config" for easy parsing later. For option parameter types, they can be set as required or optional parameters according to user selection. The parameter metadata of the option parameter type is configured with "required" to determine whether the corresponding parameter is required. In addition, the parameter metadata configured for each parameter type specifically includes description, defaultValue, validator, and required. Among them, description is used to describe the purpose of the parameter, defaultValue is the default value of the parameter, validator is the custom validation function of the parameter, such as the custom function used to check the existence of the path in the first code path, second code path, or report output path, and required is the metadata used to indicate the optionality of the option.

[0027] Specifically, during the parsing process, based on the definition of the above parameter rules, the original parameter vector is parsed into positional parameters and option parameters, generating a parameter structure, which includes parameter name, parameter type, and parameter metadata. The parameters are then categorized according to their optionality. In one possible embodiment, the parameter structure is as follows, where arguments represent required parameters and options represent optional parameters: { arguments:[ { name: 'source', description: 'first code path', required: true, validator: validatePath}, { name: 'target', description: 'Second code path', required: true, validator: validatePath} { name: 'output', description: 'Report output path', required: true, validator: validatePath} { flags: '-c, --config <file>', description: 'configuration file path', defaultValue: 'default.json', required: true}, ], options: [ { flags: '-v, --verbose', description: 'verbal output mode', defaultValue: false}, ] } This transforms the raw parameter vector input by the user into a structured data object, providing reliable input for subsequent steps.

[0028] Furthermore, each parameter after parsing needs to be verified. Specifically, this involves checking the number of parameters, whether required parameters exist, whether parameter values ​​meet constraints, or verifying the input of its own parameters based on a custom verification function. For example, verifying whether the user-inputted first code path, second code path, and report output path exist, ensuring the accuracy and reliability of subsequent code acquisition and code comparison. It is worth noting that, in a preferred embodiment, the custom verification function specifically includes file existence checks, path accessibility checks, and business logic verification.

[0029] S200. Combining the path information and the comparison configuration information, call the command-line program of the external comparison tool; In this application, user input is received through a command-line interface and converted into a command-line program for calling external comparison tools. The external comparison tools are called in silent mode through the command-line program, which improves the efficiency of code comparison and realizes the automated scheduling of external comparison tools.

[0030] In some embodiments, step S200 above includes: Load the static configuration file, prioritize and merge the static configuration file with the comparison configuration information, and generate the runtime configuration; Based on the runtime configuration, generate an executable configuration script file for the external comparison tool; Based on a predefined command template, combined with the external comparison tool and configuration script file, command line instructions are generated; The command-line instructions are executed in silent mode by creating a child process.

[0031] Specifically, a static configuration file is a text file that runs independently of the main program of the external comparison tool. It is usually in JSON, YAML, or INI format and is used to persistently store the comparison behavior rules. It provides default configuration settings for the external comparison tool, such as file filtering rules or comparison range rules. The above configuration settings remain effective until the program is reconfigured. Even if the program is closed and restarted, the configuration still exists and does not need to be reset, which facilitates unified management and maintenance of the configuration.

[0032] Furthermore, when starting the program, users can select to input specific parameters through the command-line interface to temporarily override or supplement the settings in the static configuration file, i.e., compare configuration information. This is used to temporarily adjust the behavior of the external comparison tool to adapt to special scenarios. Specifically, the comparison configuration information usually has a higher priority than the static configuration file. When the comparison configuration information conflicts with the settings in the static configuration file, the comparison configuration information entered in the command line can temporarily override the same rules defined in the static configuration file. That is, the comparison configuration information takes precedence and takes effect. This provides a balancing mechanism between default behavior and temporary special cases, enabling the external comparison tool to flexibly respond to special situations while maintaining common configurations.

[0033] Specifically, when calling an external comparison tool, a static configuration file is loaded and read to generate a basic configuration object. This basic configuration object contains default settings such as file filtering rules and comparison range rules. At the same time, based on the parsing method in step S100, the original parameter vector input from the command line is parsed to obtain the comparison configuration information. Then, the comparison configuration information is merged or overwritten with the basic configuration object to generate a runtime configuration. In subsequent processes, the external comparison tool will perform file comparison operations according to the above runtime configuration.

[0034] Furthermore, the rules in the runtime configuration are dynamically generated or configured according to the requirements of the external comparison tool to create an executable configuration script file. Simultaneously, a command template is constructed, and the absolute path, first code path, second code path, and report output path of the configuration script file are filled into the command template to generate command-line instructions. These instructions are then executed by the external comparison tool to compare the two code snippets and generate a comparison report. In some embodiments, the external comparison tools include tools capable of code comparison such as Beyond Compare, WinMerge, and Git Diff. By using these external comparison tools to compare and analyze the two code snippets, a comparison report is generated. The configuration of the script file and command-line instructions allows for data acquisition and code analysis based on the business requirements and path conditions of each external comparison tool when performing code analysis, improving the practicality and reliability of the automatic code comparison report generation method.

[0035] Furthermore, in the process of comparing and analyzing the code using an external comparison tool, it is done in the form of a subprocess. When the external comparison tool encounters an error or an unhandled exception during the comparison process and crashes, only the subprocess will be terminated, and the main control program in the automatic code comparison report generation method of this application will not crash as a result. This achieves the reliability and automated scheduling of the external comparison tool.

[0036] In some embodiments, a process listener is set in the main process of the automatic report generation method for code comparison to capture the execution output and exit code of the external comparison tool. Simultaneously, the main process waits for the child process of the external comparison tool to complete execution and determines the success or failure of the comparison task based on the exit code, thus determining the progress of the report generation process. Specifically, methods such as `process.wait()` or `process.communicate()` are called in the main process to block the current thread until the child process exits, ensuring the sequential nature of the process. When the comparison task in the child process completes, the subroutine proceeds with the subsequent report generation process based on the execution status of the comparison task. It is worth noting that the child process returns an exit code upon exit; this exit code is typically 0 for success and non-zero for failure. The main process uses the child process's exit code to determine the success or failure of the subtask, improving the reliability of the external comparison tool call.

[0037] In some embodiments, the command template includes silent execution parameters, configuration script parameters, and path information. The silent execution parameters are the parameters used by an external comparison tool when executing the command in silent mode, and the configuration script parameters are the absolute path of the configuration script file.

[0038] Specifically, the silent execution parameter is a fixed flag in the command template, used to instruct the command line instruction to perform code comparison tasks silently. That is, the external comparison tool does not encapsulate and draw a graphical user interface (GUI) when it starts up, and does not require the user to perform data input or other operations, thereby achieving uninterrupted background automation. Specifically, the silent execution parameter for Beyond Compare is / silent. The silent execution parameter is different for different external comparison tools. For example, other external comparison tools may use -quiet, --no-ui, etc., depending on the external comparison tool used by the user.

[0039] In addition, the command template includes configuration script parameters and code storage paths required for executing code comparison tasks, as well as report data paths for output. The code storage paths include a first code path and a second code path. When filling each path parameter into the response position of the command template, the corresponding path strings are enclosed in quotation marks to ensure that paths containing spaces can also be correctly parsed. Furthermore, relative paths need to be converted to absolute paths to eliminate path ambiguity. At the same time, special characters in the path strings, such as spaces, quotation marks, and shell metacharacters, are escaped or referenced to ensure that the command line instructions generated by the command template can be correctly parsed and executed in various complex path environments, greatly enhancing robustness.

[0040] S300. The code comparison process and report generation process are triggered through the command line program to generate a comparison report file.

[0041] In this application, code changes are understood from a semantic level, the analysis results of external comparison tools are semantically interpreted, intermediate data is generated, and finally integrated into a comparison report file. At the same time, the format, content and level of detail of the report can be customized according to user needs to meet the needs of different scenarios.

[0042] In some embodiments, step S300 above includes: The source code files corresponding to the first code path and the second code path are respectively parsed into a first abstract syntax tree and a second abstract syntax tree; The first abstract syntax tree and the second abstract syntax tree are compared by a tree matching algorithm to identify semantic-level changes, and semantic tags are marked for the semantic-level changes according to a predefined rule base. The semantic-level changes and semantic tags are serialized into intermediate data, and the intermediate data is integrated to generate a comparison report file through the configuration script file.

[0043] In this embodiment, when the code comparison process is triggered by the command line program, the source code files in the first code path and the second code path need to be parsed, abstracted into a syntax tree, and semantically marked according to a predetermined rule base. This facilitates the marking of changes between the two codes in the code comparison process, thereby making the generated report structured and concise, saving time for manual sorting and interpretation.

[0044] In this embodiment, the corresponding language parser is invoked according to the extensions of the first code path and the second code path. The parser performs lexical and syntactic analysis on the source code and converts it into a language-independent abstract syntax tree representation. In this abstract syntax tree, each node represents a structural element in the source code, such as function declaration, variable declaration, conditional statement, etc., and also contains information such as type, position, and identifier. This transforms the source code from a text sequence into a structured object model that can be programmatically traversed and understood.

[0045] Specifically, a static mapping table is constructed to map file extensions to language parsers one-to-one. For example, Eclipse JDT or JavaParser is used for Java, Babel or the TypeScript compiler API is used for JavaScript / TypeScript, and the ast module is used for Python.

[0046] Furthermore, the node attributes of each node in the abstract syntax tree include node name, node type, node structure, and code information. Specifically, node types include basic nodes (Node), extended nodes (Expression), and declaration nodes, while node structures include function structures such as FunctionNode, ClassNode, and ControlFlowNode. FunctionNode represents a unified function definition (parameters, return type, scope), ClassNode represents classes compatible with Java, Python, and JavaScript, and ControlFlowNode is a function structure used to encapsulate control flow such as if / for / switch. The code information includes the node's location, comments, and modifiers. The location information is represented by line numbers and column numbers. Specifically, during code conversion, it is necessary to ensure the relevance of the source code location information in the abstract syntax tree. The line number-column number mapping records the specific location of each node in the source code file, and each node is associated with a code segment in the source code to ensure that the specific location of each node in the source code can be accurately located.

[0047] In some embodiments, the step of comparing the first abstract syntax tree and the second abstract syntax tree using a tree matching algorithm to identify semantic-level changes, and labeling the semantic-level changes with semantic tags according to a predefined rule base, includes: In the first abstract syntax tree and the second abstract syntax tree, each node represents a structural element in the code; Calculate node feature values ​​for each node based on its attributes; By combining the node feature values, multi-level node matching is performed to construct matching relationships between the nodes of the first abstract syntax tree and the second abstract syntax tree; Based on the rule engine, semantic analysis is performed on the matching relationships of each node to generate semantic tags.

[0048] In this embodiment, the node type, node name, and code information are obtained from the node attributes of each node. The node feature values ​​of each node are then calculated. Specifically, the node features are quantized to generate a node feature vector v, where v = [f...]. type f name f loc f struct f sem ] T Each dimension corresponds to a feature; specifically, f type The encoded value representing the node type ensures that the encoded values ​​of the node type corresponding to nodes in different abstract syntax trees have the same meaning. name Text embedding representing node name, f loc f represents the normalized coordinates of the location information. struct f is a statistical measure of the structural characteristics of a node, i.e., the number of child nodes corresponding to a node. sem Encoding of semantic features.

[0049] Specifically, for node type encoding f type In one embodiment, one-hot encoding is used to generate a binary vector f from a predefined set of node types. type =OneHot(nodeType)∈{0,1}N, for example, in a possible embodiment, the set of node types is {"FunctionNode", "IfNode", "ClassNode","ControlFlowNode"...}, then the node type encoding for node type "FunctionNode" with a size of 5 in the set is [1, 0, 0, 0, 0]. For the node name encoding f... name In one embodiment, TF-IDF vectors are used to calculate the term frequency-inverse document frequency of names in the codebase, generating sparse vectors. For the location information encoding f... loc This normalizes the row and column coordinates to the interval [0, 1]. Specifically, assuming the maximum number of rows in the file is L and the number of columns is C, then f loc =[startLine / L, startCol / C, endLine / L, endCol / C], where startLine represents the initial line number of the code segment corresponding to the node, startCol represents the initial column number of the longest line in the code segment corresponding to the node, endLine represents the ending line number of the code segment corresponding to the node, and endCol represents the ending column number of the longest line in the code segment corresponding to the node. For the structural feature encoding f... struct Calculate the number of child nodes f corresponding to the node. child =len(node.children), and the path length f from the root node to the current node. depth , used to represent node depth, ultimately f struct =[f child f depth For semantic feature encoding f sem It maps and encodes code information such as data types and modifiers. For example, in the data type, "int" is mapped to 1, "string" is mapped to 2, etc., and in the access modifier, "public" is mapped to 0 and "private" is mapped to 1.

[0050] In this embodiment, a multi-level node matching method is used when matching the first abstract syntax tree and the second abstract syntax tree. Specifically, the node feature values ​​are compared. For nodes that are completely identical, a matching relationship is directly established. For nodes with the same node type but different other dimensions, a distance algorithm is used to calculate the content similarity of other dimensions. A matching relationship is established between nodes whose content similarity exceeds a threshold. In addition, during the matching process, for nodes whose position information dimension is inconsistent but whose other dimensions are completely identical, or whose content similarity exceeds a threshold, they are marked as node position movement. The position information of the two nodes is recorded and node matching is performed. Through multi-level matching of the two abstract syntax trees, accurate detection of code structure changes is achieved. It can identify structural changes that cannot be detected by traditional line-level comparison, thereby achieving accurate matching of the two abstract syntax trees.

[0051] In some embodiments, the step of performing semantic analysis on the matching relationships of each node and generating semantic tags based on a rule engine includes: In the rule engine, a fact object model is constructed, which is used to describe changes between nodes with matching relationships; Based on the Rete algorithm, the changed node facts are updated and matched to generate changed semantic labels, and the confidence of each semantic label is calculated. Output a set of semantic tags, each carrying a confidence level, and describe the semantic meaning of the code change through each semantic tag.

[0052] In this embodiment, a fact object model is constructed to describe the changes between nodes with matching relationships. Each fact object corresponds to the time changes of a pair of nodes with matching relationships. The fact object model includes node type, semantic label of change, and node feature value. Thus, the change relationship between nodes is transformed into standardized facts that can be processed by the rule engine, providing a structured data foundation for rule matching.

[0053] Specifically, the rule engine loads predefined semantic rules from the rule base. When an external comparison tool identifies a difference between two pieces of code, it inputs the change facts into the Rete network and performs corresponding semantic rule matching through the Rete network. In this Rete network, only the changed node facts are updated and matched to generate semantic labels and calculate confidence scores. Specifically, by optimizing the traditional Rete algorithm to be suitable for code change analysis scenarios, it updates only the changed node facts instead of processing all of them. At the same time, the rule engine prioritizes processing facts directly related to code changes to improve matching efficiency and enable it to handle change analysis of large code bases.

[0054] Specifically, in the Rete network, the state changes of each pair of matching nodes are recorded, such as adding facts, modifying facts, or deleting facts. Adding facts records the child nodes and their attributes newly added in the matching relationship between the code of the second code path and the code of the first code path, or the child nodes and their attributes newly added in the matching relationship between the code of the second code path and the code of the first code path. Modifying facts record the modified and changed attributes between matching nodes. Deleting facts record the node identifiers deleted between matching nodes.

[0055] In some embodiments, changes are categorized into different priorities based on their type and scope of impact. For example, high-priority changes represent significant changes such as interface or structural modifications, medium-priority changes represent changes such as logic refactoring or algorithm optimization, and low-priority changes represent minor changes such as comment modifications or format adjustments. When generating a comparison report, the corresponding changes are marked according to their priority, such as high-priority changes in red, medium-priority changes in blue, and low-priority changes in green. This facilitates quick access to information about changes for users, ensures that important changes are addressed first, and improves the timeliness of analysis.

[0056] Furthermore, in this embodiment, the Rete algorithm is an incremental Rete network update algorithm. When adding or modifying facts, the incremental update algorithm is used to connect the new facts with the existing matching results and propagate the changes to the affected downstream nodes. This algorithm maintains the state information with matching relationships and avoids recalculating the entire network.

[0057] In the rule base, semantic rules are defined declaratively. Action matching is only required based on the change type in the comparison results of the code comparison tool. The change type is specifically code change or node attribute change, etc. For facts with complex logical changes, conditional expressions are used for matching, such as logical OR || or attribute comparison parameterCountChanged == true. Thus, complex logic can be constructed based on node attributes, relationships, or change types. When the above predefined change semantic rules appear in the comparison results of the code comparison tool, the action is triggered to execute, specifically by adding semantic tags and calculating confidence. In particular, each semantic rule is set with a semantic tag to describe the code change situation.

[0058] Specifically, each rule defined in the rule base has a base confidence weight, which is dynamically adjusted based on the change facts generated in the code comparison results to generate the confidence of the corresponding semantic label. When a change fact corresponds to multiple semantic rules, the corresponding semantic label can be determined based on the confidence. For example, in one embodiment, a confidence threshold is provided. When multiple semantic rules conflict, semantic rules below the confidence threshold can be filtered to ensure the reliability and accuracy of semantic analysis.

[0059] Furthermore, in one possible embodiment, the semantic tags corresponding to the semantic rules include structural changes, logical changes, quality changes, and destructive changes. Each semantic tag is further refined, such as refining structural changes into class structure changes, interface structure changes, and function structure changes; refining logical changes into algorithm changes and flow control changes; refining quality changes into performance optimizations; and destructive changes specifically refer to changes that affect compatibility.

[0060] Specifically, for a change, there may be one or more semantic tags. These multiple semantic tags are then combined into a semantic tag set for output. Each semantic tag is sorted according to its confidence level, and the semantic tags describe the semantic meaning of the code change.

[0061] Furthermore, in this embodiment, the results of the semantic analysis are serialized into intermediate data, which is specifically a change list. Each change item records its file, line number range, semantic tag, brief description, and change priority. In addition, the format of the intermediate data is specifically JSON or XML.

[0062] It is worth noting that this application requires the use of configuration script files from external comparison tools to analyze the changes in the two codes. Based on the analysis results, the corresponding code changes are semantically interpreted to generate intermediate data, which is then finally integrated into a comparison report file. The comparison report file can be in HTML or XML format, etc. Specifically, the format, content, and level of detail of the report can be customized according to user needs to meet the requirements of different scenarios.

[0063] Please see Figure 2 As shown, the present invention also provides an automatic code comparison report generation system, the system comprising: First processing module 201: used to receive path information and comparison configuration information input by the user through the command line interface; The second processing module 202 is used to combine the path information and the comparison configuration information to call the command line program of an external comparison tool; The third processing module 203 is used to trigger the code comparison process and report generation process through the command line program, and generate a comparison report file.

[0064] It is understandable that, such as Figure 1 The content of the code comparison report automatic generation method embodiment shown is applicable to this code comparison report automatic generation system embodiment. The specific functions implemented by this code comparison report automatic generation system embodiment are the same as those shown. Figure 1 The code comparison report automatic generation method shown is the same as the embodiment, and the beneficial effects achieved are the same as those shown. Figure 1 The beneficial effects achieved by the example of the automatic code comparison report generation method shown are also the same.

[0065] It should be noted that the information interaction and execution process between the above systems are based on the same concept as the method embodiments of the present invention. For details on their specific functions and technical effects, please refer to the method embodiments section, which will not be repeated here.

[0066] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0067] Please see Figure 3 As shown, this embodiment of the invention also provides a computer device 3, including: a memory 302 and a processor 301, and a computer program 303 stored on the memory 302. When the computer program 303 is executed on the processor 301, it implements the code comparison report automatic generation method as described in any of the above methods.

[0068] The computer device 3 may be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device 3 may include, but is not limited to, a processor 301 and a memory 302. Those skilled in the art will understand that... Figure 3 The computer device 3 is merely an example and does not constitute a limitation on the computer device 3. It may include more or fewer components than shown in the figure, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0069] The processor 301 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0070] In some embodiments, the memory 302 may be an internal storage unit of the computer device 3, such as a hard disk or memory of the computer device 3. In other embodiments, the memory 302 may be an external storage device of the computer device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 3. Furthermore, the memory 302 may include both internal and external storage units of the computer device 3. The memory 302 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory 302 can also be used to temporarily store data that has been output or will be output.

[0071] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the code comparison report automatic generation method as described in any of the above methods.

[0072] In this embodiment, if the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographic device / computer device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0073] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.< / file> < / source-path> < / target-path> < / source-path>

Claims

1. A method for automatically generating code comparison reports, characterized in that, include: Receive path information and comparison configuration information input by the user through the command-line interface; Combining the path information and the comparison configuration information, the command-line program of an external comparison tool is invoked; The command-line program triggers the code comparison process and report generation process, generating a comparison report file.

2. The method as described in claim 1, characterized in that, The process of receiving path information and comparison configuration information input by the user via the command-line interface includes: The system captures the raw parameter vector of the command line input and uses a command line parameter parsing library to perform structured parsing and verification of the raw parameter vector, generating path information and comparison configuration information. The path information includes a first code path, a second code path, and a report output path.

3. The method as described in claim 1, characterized in that, The command-line program that combines the path information and the comparison configuration information to call an external comparison tool includes: Load the static configuration file, prioritize and merge the static configuration file with the comparison configuration information, and generate the runtime configuration; Based on the runtime configuration, generate an executable configuration script file for the external comparison tool; Based on a predefined command template, combined with the external comparison tool and configuration script file, command line instructions are generated; The command-line instructions are executed in silent mode by creating a child process.

4. The method as described in claim 3, characterized in that, The command template includes silent execution parameters, configuration script parameters, and path information. The silent execution parameters are the parameters used by the external comparison tool when executing the command in silent mode, and the configuration script parameters are the absolute path of the configuration script file.

5. The method as described in claim 3, characterized in that, The process of triggering the code comparison process and report generation process through the command-line program to generate a comparison report file includes: The source code files corresponding to the first code path and the second code path are respectively parsed into a first abstract syntax tree and a second abstract syntax tree; The first abstract syntax tree and the second abstract syntax tree are compared by a tree matching algorithm to identify semantic-level changes, and semantic tags are marked for the semantic-level changes according to a predefined rule base. The semantic-level changes and semantic tags are serialized into intermediate data, and the intermediate data is integrated to generate a comparison report file through the configuration script file.

6. The method as described in claim 5, characterized in that, The step of comparing the first abstract syntax tree and the second abstract syntax tree using a tree matching algorithm to identify semantic-level changes, and labeling the semantic-level changes with semantic tags according to a predefined rule base, includes: In the first abstract syntax tree and the second abstract syntax tree, each node represents a structural element in the code; Calculate node feature values ​​for each node based on its attributes; By combining the node feature values, multi-level node matching is performed to construct matching relationships between the nodes of the first abstract syntax tree and the second abstract syntax tree; Based on the rule engine, semantic analysis is performed on the matching relationships of each node to generate semantic tags.

7. The method as described in claim 6, characterized in that, The process of using a rule engine to perform semantic analysis on the matching relationships of each node and generate semantic tags includes: In the rule engine, a fact object model is constructed, which is used to describe changes between nodes with matching relationships; Based on the Rete algorithm, the changed node facts are updated and matched to generate changed semantic labels, and the confidence of each semantic label is calculated. Output a set of semantic tags, each carrying a confidence level, and describe the semantic meaning of the code change through each semantic tag.

8. A code comparison report automatic generation system, characterized in that, include: The first processing module is used to receive path information and compare configuration information input by the user through the command line interface. The second processing module is a command-line program used to combine the path information and the comparison configuration information to call an external comparison tool. The third processing module is used to trigger the code comparison process and report generation process through the command-line program, and generate a comparison report file.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 7.

Images