Method and apparatus for generating code-based module design document

Abstract

This application provides a method and apparatus for generating code-based module design documents. The method includes: obtaining target code; deleting compiler directives and comments from the target code to obtain code text; identifying and extracting global variables and function structures from the code text; comparing the identifiers in each function structure in parallel with global variables, and comparing the identifiers before the left parenthesis in each function structure in parallel with the function names of other function structures, and associating the global variables and / or function names that match the comparison with the corresponding function structures, wherein the other function structures are the function structures outside the current function structure in each function structure; and generating and outputting a target module design document in a preset format based on each function structure and its associated global variables and / or function names. This achieves efficient and accurate generation of module design documents.

Description

Technical Field

[0001] This application relates to the field of computer software engineering and development technology, and in particular to a method for generating code-based module design documents, an apparatus for generating code-based module design documents, a computer device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] In the field of software engineering, module design is a crucial link in the development process from requirements analysis to final code implementation. It aims to decompose abstract system requirements into concrete, structured software modules, define the functions, interfaces, and dependencies of each module, and create module design documents. This provides a fundamental basis for subsequent coding, testing, integration, and maintenance activities. Furthermore, to ensure consistency between software design and implementation, improve document maintainability, and reduce the risk of errors and delays caused by manual coding and updates, it is necessary to generate and output target module design documents in a pre-defined format based on the code.

[0003] Currently, generating and outputting target module design documents in a pre-defined format based on code primarily relies on developers manually extracting and compiling text based on their personal experience. Specifically, developers first read through the target code, relying on their mastery of the programming language and their subjective understanding to identify and mark key code structures in their minds, such as function signatures, parameter lists, and cross-module call chains. Then, they manually categorize and organize the identified information according to a predetermined document framework, gradually filling in structured descriptive text. This process yields the module design document for the target code.

[0004] However, in the process of manually generating and outputting target module design documents in a pre-defined format, developers must invest a significant amount of time reading code line by line, manually extracting key elements, and organizing information according to standardized formats. This process not only requires a continuous and substantial investment of manual labor, but also, in scenarios with complex code structures or a large number of modules, the processing time increases linearly or even exponentially, leading to overall inefficiency in document generation. This, in turn, severely strains development resources and delays project progress. Summary of the Invention

[0005] The purpose of this application is to provide a method, apparatus, computer device, computer-readable storage medium, and computer program product for generating code-based module design documents, so as to improve the efficiency of module design document generation.

[0006] To address the aforementioned technical problems, this application provides the following technical solutions: The first aspect of this application provides a method for generating a code-based module design document. The method includes: obtaining target code; deleting compiler directives and comments from the target code to obtain code text; identifying and extracting global variables and function structures from the code text; comparing the identifiers in each function structure in parallel with global variables, and comparing the identifiers before the left parenthesis in each function structure in parallel with the function names of other function structures, and associating the global variables and / or function names that match the comparison with the corresponding function structures, wherein the other function structures are the function structures in each function structure excluding the current function structure; and generating and outputting a target module design document in a preset format based on each function structure and its associated global variables and / or function names.

[0007] Compared to existing technologies, the code-based module design document generation method provided in the first aspect of this application first obtains clean code text by removing compiler directives and comments, avoiding interference from non-functional code in the analysis. Then, it intelligently identifies global variables and function structures, and through parallel comparison, accurately associates functions with global variables and the call relationships between functions, ensuring the comprehensiveness and reliability of code structure analysis. Finally, it automatically generates documents in a preset format based on structured information, achieving efficient and accurate generation of module design documents. Simultaneously, through an automated and structured analysis process, it effectively supports the maintainability of large-scale software projects, team collaboration efficiency, and the traceability of code changes, providing a reliable technical documentation foundation for software development and maintenance.

[0008] In other embodiments provided in this application, identifying and extracting global variables and function structures from code text includes: identifying non-identifier character sequences outside the keyword set from the code text to obtain candidate variables, wherein the keyword set includes keywords corresponding to the programming language; identifying function structures from the code text; if a candidate variable is located outside the function structure and the next character of the candidate variable in the code text is not a left parenthesis, then the candidate variable is determined to be a global variable.

[0009] By comprehensively judging based on keyword set exclusion and function body position and character context, global variables are accurately identified and extracted, effectively avoiding misjudging local variables or function names as global variables, thus significantly improving the accuracy and reliability of global variable extraction.

[0010] In other embodiments provided in this application, identifying the function structure from the code text includes: traversing each line of the code text in parallel; if a left parenthesis exists, backtracking to the left and extracting the identifier before a space or operator to obtain the function name; traversing the code text starting from the function name; if a left parenthesis is encountered, incrementing the counter by 1; if a right parenthesis is encountered, decrementing the counter by 1; and obtaining the traversal content from 1 to 0, determining the traversal content as the function text.

[0011] By using a counter to accurately match curly brace pairs and combining parallel traversal with backtracking of the left bracket, the start and end boundaries of the function body can be reliably determined, thereby significantly improving the completeness and accuracy of function text extraction in complex nested or irregularly structured code.

[0012] In other embodiments provided in this application, after determining the traversed content as the function text, the method further includes: starting from the second line of the function text, extracting the content to the left of the function name to obtain the return type, and determining the specific type and return logic path of the return type based on the characteristics of the programming language type of the target code. The specific type includes one of basic type, composite type, and generic type; extracting the parameter string between the left and right parentheses, and identifying the data type and variable name of the parameter from the parameter string; generating and outputting a target module design document in a preset format based on each function structure and its associated global variables and / or function names, including: generating and outputting a target module design document in a preset format based on each function name and its corresponding return type, start and end line numbers, data type and variable name of the parameter, and its associated global variables and / or function names.

[0013] By systematically extracting and parsing return type and parameter information from function definition lines and associating it with structured function bodies, a complete and accurate view of function metadata can be constructed. This lays a solid foundation for automatically generating detailed and formatted module design documents, significantly improving the technical accuracy and information completeness of the documents.

[0014] In other embodiments provided in this application, deleting compiler directives and comments in the target code to obtain code text includes: deleting comments in the target code to obtain a first intermediate text; deleting macro definitions in the first intermediate text to obtain a second intermediate text; and deleting alternative branch conditions in the second intermediate text to obtain code text.

[0015] By sequentially removing comments, macro definitions, and alternative branches in conditional compilation, a layer-by-layer purification preprocessing flow was constructed, effectively stripping away non-functional code and optional logic branches, thereby significantly improving the purity, consistency, and accuracy of subsequent code structure identification and analysis.

[0016] In other embodiments provided in this application, before deleting the compiler directives and comments in the target code, the method further includes: identifying the programming language type of the target code; deleting the compiler directives and comments in the target code, including: deleting the compiler directives and comments in the target code based on the programming language type; identifying and extracting global variables and function structures from the code text, including: identifying and extracting global variables and function structures from the code text based on the programming language type.

[0017] By first identifying and adapting to specific programming language types, and then executing targeted preprocessing and structure extraction rules, the parsing obstacles caused by differences in the syntax of different languages ​​are effectively overcome, thereby significantly improving the system's compatibility with multilingual code, processing accuracy, and overall robustness.

[0018] In other embodiments provided in this application, a target module design document in a preset format is generated and output based on each function structure and its associated global variables and / or function names, including: generating a call relationship graph based on each function structure and its associated global variables and / or function names; and generating and outputting a target module design document in a preset format containing the call relationship graph.

[0019] By integrating discrete function call relationships into a visual call relationship graph, the logical dependencies and interaction patterns within a module can be revealed intuitively, thereby significantly improving the comprehensibility of module design documents, the efficiency of architecture review, and the effectiveness of team collaboration and communication.

[0020] In other embodiments provided in this application, the target module design document includes module design documents corresponding to different versions of the target code. The module design document includes each function name and its corresponding return type, start and end line numbers, parameter data types and variable names, involved global variables, and called function names. After generating and outputting the target module design document in a preset format, the method further includes: comparing the different module design documents according to function names, return types, start and end line numbers, parameter data types and variable names, involved global variables, and called function names; and generating a difference report based on the differences between the current version of the target code and the previous version of the target code in function names, return types, start and end line numbers, parameter data types and variable names, involved global variables, and called function names.

[0021] By performing structured, multi-dimensional, and automated comparisons between different versions of module design documents, the specific location and scope of code changes can be quickly and accurately identified, thereby significantly improving the efficiency and reliability of version iteration analysis, code review, and change management.

[0022] In other embodiments provided in this application, after generating the difference report, the method further includes: receiving a version of target code specified from different versions of target code; obtaining a module design document corresponding to the specified target code; obtaining a difference report corresponding to the specified target code and its previous version of target code; and marking the obtained module design document based on the obtained difference report to obtain the final module design document of the specified target code.

[0023] By automatically tagging and integrating the content of version difference reports into the latest version of the module design document, the evolution history and change details of the code can be presented intuitively, thereby significantly improving the document's version traceability capabilities, the efficiency of context sharing in team collaboration, and the consistency of project maintenance.

[0024] A second aspect of this application provides an apparatus for generating a code-based module design document. The apparatus includes: an acquisition module for acquiring target code; a preprocessing module for deleting compiler directives and comments from the target code to obtain code text; an identification and extraction module for identifying and extracting global variables and function structures from the code text; a deep parsing module for comparing identifiers in each function structure in parallel with global variables, and comparing identifiers before the left parenthesis in each function structure in parallel with function names of other function structures, and associating matching global variables and / or function names with corresponding function structures, wherein other function structures are function structures other than the current function structure in each function structure; and an output generation module for generating and outputting a target module design document in a preset format based on each function structure and its associated global variables and / or function names.

[0025] A third aspect of this application provides a computer device including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the method of the first aspect.

[0026] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method of the first aspect.

[0027] The fifth aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the method of the first aspect.

[0028] The code-based module design document generation apparatus provided in the second aspect of this application, the computer device provided in the third aspect, the computer-readable storage medium provided in the fourth aspect, and the computer program product provided in the fifth aspect have the same or similar beneficial effects as the code-based module design document generation method provided in the first aspect. Attached Figure Description

[0029] The above and other objects, features, and advantages of exemplary embodiments of this application will become readily understood by reading the following detailed description with reference to the accompanying drawings. In the drawings, several embodiments of this application are illustrated by way of example and not limitation, with the same or corresponding reference numerals denoteing the same or corresponding parts, wherein: Figure 1 This is a flowchart illustrating the method for generating code-based module design documents in the embodiments of this application. Figure 1 ; Figure 2 This is a flowchart illustrating the method for generating code-based module design documents in the embodiments of this application. Figure 2 ; Figure 3 This is a schematic diagram of the structure of the code-based module design document generation device in the embodiments of this application. Figure 1 ; Figure 4 This is a schematic diagram of the structure of the code-based module design document generation device in the embodiments of this application. Figure 2 ; Figure 5 This is a schematic diagram of the structure of the computer device in the embodiments of this application. Detailed Implementation

[0030] Exemplary embodiments of this application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of this application and to fully convey the scope of this application to those skilled in the art.

[0031] It should be noted that, unless otherwise stated, the technical or scientific terms used in this application shall have the ordinary meaning as understood by one of ordinary skill in the art to which this application pertains.

[0032] Currently, the method of manually generating module design documents mainly has the following technical problems: First, it relies heavily on human experience, making it difficult to guarantee the consistency of document quality and resulting in low generation efficiency; second, as the code size increases or the structure becomes more complex, manually extracting information becomes time-consuming and prone to omissions or errors; third, document updates lag behind code changes, making it difficult to maintain consistency between design and implementation, and increasing project maintenance risks and costs.

[0033] The root cause of these technical problems lies in the fact that traditional methods of generating module design documents heavily rely on developers' subjective understanding and manual operations, lacking a mechanism to automatically and systematically extract structured information from source code and map it into design documents. This results in a process that is not only highly repetitive and intolerant of errors, but also difficult to synchronize with dynamically iterating codebases, making it impossible to effectively guarantee the accuracy, timeliness, and maintainability of the documents.

[0034] In view of this, embodiments of this application provide a method, apparatus, computer device, computer-readable storage medium, and computer program product for generating code-based module design documents. By constructing an automated processing chain from code acquisition, preprocessing, structure recognition, relationship association, to document generation, the process, which previously relied on manual understanding and organization, is transformed into a systematic operation based on rules and algorithms. The core is to treat code as a structured data source, using programmatic methods to remove irrelevant symbols, identify key elements, establish relationships, and ultimately automatically synthesize standard documents through template-driven processes. This fundamentally eliminates the inefficiencies and errors introduced by human factors, significantly improving the efficiency, accuracy, and consistency of the document generation process.

[0035] It should be noted that the user data, data acquisition, and / or use involved in the embodiments of this application strictly comply with the laws, regulations, and industry standards of relevant countries and regions. The collection and acquisition of data involved in the embodiments of this application are all done in advance by actively prompting or prominently displaying information to inform users and obtaining authorization, or by obtaining full authorization from all parties. The processing, manipulation, forwarding, and use of data involved in the embodiments of this application are all carried out on the premise that the user or relevant party is fully informed and authorized. In implementing the various embodiments of this application, the types of data or information, scope of use, and usage scenarios that may be involved are informed to users or relevant parties and authorization is obtained through appropriate means. The specific methods of notification and authorization may vary according to the actual situation, and this application is not limited in this regard. The processing of personal information involved in the embodiments of this application is carried out under the premise of having a legal basis (such as obtaining the consent of the personal information subject or being necessary for the performance of a contract), and is only processed within the prescribed or agreed scope. Sensitive personal information such as biometric information, medical and health information, financial account information, and precise location information involved in the embodiments of this application are all processed under the premise of having a specific purpose and sufficient necessity, and with the separate authorization and consent of the user or relevant party. In some embodiments of this application, if the user or related party refuses to process personal information other than the information necessary for the basic functions, it will not affect the use of the basic functions of the embodiments of this application.

[0036] First, the method for generating code-based module design documents provided in the embodiments of this application will be described in detail.

[0037] Figure 1 This is a flowchart illustrating the method for generating code-based module design documents in the embodiments of this application. Figure 1 See Figure 1 As shown, the method may include: S11: Obtain the target code.

[0038] The target code here refers to the source code to be analyzed and used to generate module design documents. It can be a complete software project, a standalone code file, or a segment of code within a file. The specific content of the target code is not limited here.

[0039] In practice, the target code can be obtained from the version control system to track historical versions of the code, compare module design differences between different branches or tags, and ensure that the document generation is based on a specific release version of the code, thereby supporting the purpose of versioned document management and release auditing.

[0040] It can also obtain target code from integrated development environments or continuous integration / continuous deployment pipelines to achieve real-time and automatic acquisition of the current working code during development or build, thereby seamlessly embedding the generation of module design documents into the development process and ensuring that the documents are synchronized with the latest code.

[0041] It can also obtain target code from the code audit or review process to perform structured analysis on the compliance, security or quality of specific submissions or code snippets, and automatically generate standardized design views for review, thereby improving audit efficiency and consistency.

[0042] It can also retrieve target code when the document automation generation task is triggered, so as to automatically and regularly update design documents according to plan (such as after daily build) or event (such as new version release), to ensure the timeliness of the project document library and reduce the lag of manual maintenance.

[0043] It can also obtain target code during the maintenance and refactoring phases to accurately locate and analyze the modules to be modified and their dependencies, providing a basis for understanding the existing code structure, assessing the scope of impact, and generating design comparison documents before and after refactoring, thereby reducing maintenance risks.

[0044] S12: Delete the compiler directives and comments in the target code to obtain the code text.

[0045] Compiler directives are instructions in source code that begin with a specific symbol (such as #) and are used to instruct the compiler or preprocessor to perform operations such as text substitution, conditional compilation, or file inclusion before the compilation (or interpretation) phase. Examples include #include, #define, #ifdef, and #pragma in C / C++.

[0046] Comments are text snippets inserted into source code to explain the functionality, logic, or intent of the code to developers. Examples include single-line comments (such as / / comment) and multi-line comments (such as / * comment * / ).

[0047] When deleting compiler directives, a line-wide deletion based on the line start identifier can be used. Specifically, each line of the target code is traversed, and it is checked whether the line begins with a specific starting symbol for the compiler directive (such as #). If so, the entire line is determined to be a compiler directive line and is completely deleted from the text.

[0048] Alternatively, a structured deletion and selective retention approach based on syntax rules can be employed. Specifically, for complex compiler directive structures (such as conditional compilation blocks `#ifdef ... #else ... #endif`), instead of simple line-by-line deletion, they are parsed according to their syntax rules. Specifically, the beginning of the conditional compilation block (e.g., `#ifdef COND`), optional middle sections (e.g., `#else`), and the ending marker (`#endif`) are identified, and only content outside the predefined conditional branches is selectively deleted (e.g., when retaining the `#ifdef` branch, all code between `#else` and `#endif` is deleted).

[0049] When deleting comments, regular expressions can be used for matching and replacement. Specifically, a regular expression pattern is constructed to match all comment text in the source code. For single-line comments, the pattern matches all characters from / / to the end of the line. For multi-line comments, the pattern matches all content from / * to * / . All matched comment text is then replaced with an empty string, thus achieving deletion.

[0050] Alternatively, a character-by-character scanning and filtering based on a state machine can be used. Specifically, a finite state machine mechanism is used to scan the target code character by character, maintaining a state indicating whether it is inside a comment. The initial state is "non-comment". When a comment start character (such as / / or / *) is encountered, the state switches to "in a single-line comment" or "in a multi-line comment", and subsequent characters are ignored until the corresponding comment end character (line end or * / ) is encountered. At this point, the state switches back to "non-comment", and code characters are processed normally.

[0051] S13: Identify and extract global variables and function structures from code text.

[0052] Global variables are variables declared outside of function, method, or class definitions. Their scope spans the entire program or module, persisting throughout the program's lifecycle or during module loading, and can be accessed and modified by multiple functions or code blocks.

[0053] A function structure is an executable code unit defined in the code, containing a function name, return type, parameter list, and a function body (i.e., a sequence of statements enclosed in curly braces {}) that implements the specific functionality. A function structure completely describes an independent functional operation.

[0054] When identifying and extracting global variables, keyword exclusion and the position outside function bodies and character context (excluding left parentheses) can be used. Alternatively, a syntax tree or abstract syntax tree can be constructed to perform semantic-level scope analysis. Specifically, all variable declaration nodes are located in the syntax tree, and their parent nodes are traversed upwards to the root node. If the scope of a variable declaration node does not belong to any function definition node, class definition node, or local code block node (i.e., its scope chain is topped by the global scope), then the variable is determined to be a global variable. This method can more accurately distinguish between global variables and variables defined in deeply nested blocks but whose scope is still local, and effectively handles complex scope boundary situations caused by macro expansion or conditional compilation, improving identification accuracy.

[0055] When specifically identifying and extracting function structures, the function name can be extracted by locating the left parenthesis "()" in the function definition line and then using curly braces "{}" for counting and matching to determine the complete scope of the function body, thereby extracting the structure containing the function name and function body. Alternatively, function structure identification and extraction can be based on an abstract syntax tree (AST). Specifically, a parser corresponding to the target code programming language (such as Clang for C / C++) is first used to perform syntactic analysis on the preprocessed code text, generating a structured AST. In this AST, function definitions typically correspond to specific node types. By traversing the AST, all function definition nodes are located, and the precise function name, return type, parameter list, and function body (i.e., the subtree or code block corresponding to the function body) are directly extracted from the node attributes. Finally, the extracted information is encapsulated into a structured function structure. This method does not rely on character-level pattern matching of the original text but utilizes the parsing capabilities of the compiler front-end, thus offering higher accuracy, robustness, and better support for modern programming languages ​​with complex syntax features.

[0056] S14: Compare the identifiers in each function structure with global variables in parallel, and compare the identifiers before the left parenthesis in each function structure with the function names of other function structures in parallel. Associate the global variables and / or function names that match the comparison with the corresponding function structures. The other function structures are the function structures in each function structure excluding the current function structure.

[0057] In other words, the various function structures obtained from the target code are processed in parallel, meaning multiple parsers are used in parallel to perform in-depth parsing on each function structure. Each parser can correspond to one function structure or several function structures. The specific correspondence between parsers and function structures can be evenly distributed based on the number of parsers and function structures.

[0058] Specifically, on the one hand, it identifies global variables used within functions. It iterates through the text of each function structure, extracting all identifiers that appear within it. These identifiers are then compared in parallel with the previously extracted global variables. If an identifier completely matches one of the global variables, it is assumed that the function uses this global variable, and the global variable information (such as variable name and type) is recorded at the corresponding location in the function structure, establishing a connection.

[0059] Here, identifiers refer to character sequences defined by the syntax rules of programming languages ​​in code text, used to name various entities in the program. In other words, they are strings extracted from the text of function structures through lexical analysis or simple pattern matching that conform to the above naming rules and are used to represent potential variable names or function names.

[0060] Meanwhile, on the other hand, the function identifies other functions called within its own structure. Similarly, it iterates through the text of each function structure, searching for identifiers immediately followed by a left parenthesis "(", e.g., functionName(). The identifiers preceding these left parentheses are extracted. These identifiers are then compared to the function names of all function structures. If an extracted identifier matches the name of another function, it is assumed that the current function has called that function, and the information of the called function is recorded at the corresponding location in the current function structure, establishing a connection.

[0061] S15: Generate and output a target module design document in a preset format based on each function structure and its associated global variables and / or function names.

[0062] The target module design document will systematically organize and present the following core content: 1. A cover page and automatic table of contents including titles, generation time, version numbers, etc.; 2. A module-level function overview, including statistical information (such as the total number of functions, the number of functions with parameters, etc.) and optional insertion of statistical charts; 3. A detailed list of each function in groups (such as by file path) and item by item, specifically including a section titled with the function name, under which the basic information of the function (such as return type, start and end line numbers), parameter list (listing the type and name of each parameter in tabular form), global variable dependency list (if it exists), and internal reference function list (i.e., the called functions, listed with bullet points); If the system has undergone multi-version code analysis, the document will also include a separate section comparing version differences. This section will be categorized (such as additions, deletions, modifications) and marked with colors or styles (such as green for additions, red for deletions) to clearly show the specific differences between different versions at the function level. Ultimately, the generated documentation can be directly used as an Application Programming Interface (API) manual, code description, or version change report, achieving a fully automated, high-fidelity conversion from code to standardized design documentation.

[0063] As described above, the code-based module design document generation method provided in this application first obtains clean code text by deleting compiler directives and comments, avoiding interference from non-functional code in the analysis. Then, it intelligently identifies global variables and function structures, and accurately associates functions with global variables and the call relationships between functions through parallel comparison, ensuring the comprehensiveness and reliability of code structure analysis. Finally, it automatically generates a document in a preset format based on structured information, achieving efficient and accurate generation of module design documents. Simultaneously, through an automated and structured analysis process, it effectively supports the maintainability of large software projects, team collaboration efficiency, and the traceability of code changes, providing a reliable technical documentation support foundation for software development and maintenance.

[0064] Furthermore, as a response to Figure 1 In addition to refining and extending the method shown, this application also provides a method for generating code-based module design documents.

[0065] Figure 2 This is a flowchart illustrating the method for generating code-based module design documents in the embodiments of this application. Figure 2 See Figure 2 As shown, the method may include: S21: Obtain the target code.

[0066] Step S21 here is implemented in the same way as step S11 in the previous embodiment. Please refer to the relevant description in the previous embodiment. It will not be repeated here.

[0067] S22: Identify the programming language type of the target code.

[0068] First, a preliminary quick identification is performed based on the file extension (e.g., .c files correspond to C, .java files to Java, and .py files to Python). For files with no extension or an ambiguous extension, further content feature analysis is conducted. The content at the beginning of the file is read and scanned for the presence of keywords specific to a particular programming language (e.g., #include for C / C++, def for Python, public class for Java), unique syntax structures (e.g., Python's indentation-sensitive syntax, shell scripts' #! / bin / bashshebang lines), or comment symbols (e.g., / / , / * * / , #, etc.). Using a built-in feature rule library of known programming languages, these features are matched and confidence scores are calculated to ultimately determine the most likely programming language type.

[0069] On the one hand, compiler directives and comments in the target code can be deleted directly based on the programming language type. On the other hand, comments, macro definitions, and alternative branch conditions in the target code can be deleted sequentially based on the programming language type to precisely remove content in the target code that is irrelevant to function identification.

[0070] S23: Based on the programming language type, remove comments from the target code to obtain the first intermediate text; remove macro definitions from the first intermediate text to obtain the second intermediate text; remove alternative branch conditions from the second intermediate text to obtain the code text.

[0071] First, remove comments. For C, identify and remove all single-line comments starting with " / / " and their subsequent content, as well as all multi-line comments (including those spanning multiple lines) between " / ". Next, remove macro definitions. In the first intermediate text, identify and completely remove all statements starting with "#define". Finally, remove alternative branch conditions. In the second intermediate text, identify the conditional compilation structure "#ifdef ... #else ... #endif", and focus on removing all code between the "#else" statement and its corresponding "#endif" statement, retaining only the code segment under the "#ifdef" condition. This ensures that subsequent analysis is based on a single, deterministic code logic path.

[0072] For Python, first, remove comments. Identify and remove all single-line comments that begin with a hash symbol "#" and their subsequent content. For multi-line string literals, remove them if they appear outside the beginning of a module, class, or function definition, or if heuristically determine they are non-docstring comments. Next, remove macro definitions. While Python doesn't have macros like C, it does have statements that affect compilation behavior, such as `__future__` imports, and conditional import logic that may be included in `import` statements. These statements are usually retained because they are part of the code logic. Finally, remove alternative branch conditions. Conditional execution structures (such as code blocks used for testing or examples in `if False:` or `if __name__ == '__main__':`) can be identified, and code content under specific branches can be selectively removed based on configuration to ensure the analysis focuses on the core logic.

[0073] In summary, there are significant differences in the specific forms and processing methods of comments, macro definitions, and alternative branch conditions in different programming languages. Corresponding deletion rules and processing strategies can be set in advance according to the syntax specifications of each language to achieve accurate code text preprocessing.

[0074] S24: Based on the programming language type, identify non-identifier character sequences outside the keyword set from the code text to obtain candidate variables. The keyword set includes the keywords corresponding to the programming language. Identify function structures from the code text. If a candidate variable is located outside the function structure and the next character of the candidate variable in the code text is not a left parenthesis, then the candidate variable is determined to be a global variable.

[0075] Taking the C language as an example, the keyword set includes at least the following: "auto", "break", "case", "char", "const", "continue", "default", "do", "double", "else", "enum", "extern", "float", "for", "goto", "if", "int", "long", "register", "return", "short", "signed", "sizeof", "static", "struct", "switch", "typedef", "union", "unsigned", "void", "volatile", and "while".

[0076] When identifying candidate variables, the preprocessed code text is traversed to identify all character sequences that conform to identifier naming rules (such as starting with a letter or underscore and consisting of letters, numbers, and underscores). Each character sequence is then compared to the aforementioned set of keywords. If a character sequence does not belong to this set of keywords, it is initially marked as a candidate variable. For example, the character sequences totalCount, buffer, and MAX_SIZE appearing in the code text are all identified as candidate variables if they are not C language keywords.

[0077] When identifying a function structure, taking C as an example (other programming languages ​​can be modified based on their characteristics), first, locate the function definition line. In the code text, find lines containing a left parenthesis "(" followed by a parameter list and a right parenthesis ")", and where the right parenthesis is immediately followed by a left curly brace "{" or a newline is followed by a left curly brace "{". Next, extract the function name. In the function definition line, start from the position of the left parenthesis "(" and trace back, skipping whitespace characters, extracting the sequence of characters until a whitespace character or operator is encountered; this is the function name. Finally, determine the function body. Starting from the function definition line, from the appearance of the left curly brace "{" to the encounter of the right curly brace "}", all the lines of code traversed are determined as the complete body of the function. The function name and its corresponding complete body together constitute a function structure.

[0078] However, in scenarios with nested code blocks (such as conditional statements or code blocks inside loops), simple pattern matching alone cannot accurately define the start and end positions of the function body. To solve the problem of incorrect function text boundary identification caused by nested curly braces, a counter is used to accurately match the outermost curly brace pair of the function definition.

[0079] Specifically, step S24 above may include: S241: For each line of code text, iterate in parallel. If a left parenthesis exists, backtrack to the left and extract the identifier before the space or operator to obtain the function name.

[0080] S242: In the code text, start traversing from the function name. If a left parenthesis is encountered, increment the counter by 1. If a right parenthesis is encountered, decrement the counter by 1. Obtain the traversal content from 1 to 0 and determine the traversal content as the function text.

[0081] Specifically, the code text is scanned line by line to locate potential function definitions. When a left parenthesis "(" is detected in a line (which usually marks the beginning of a parameter list), the code traces back to the left from that parenthesis position, skipping whitespace characters, until a space or operator (such as * or &) is encountered. The sequence of characters in between is extracted as a candidate function name, and further verification (such as checking that it is not a keyword and that a right parenthesis is immediately followed by a left curly brace) confirms that it is a valid function definition line, thus obtaining the function name.

[0082] After the function definition is determined, a curly brace counter is initialized to 0, and the subsequent code is traversed starting from that line. Each time a left curly brace "{" is encountered, the counter is incremented by 1; each time a right curly brace "}" is encountered, the counter is decremented by 1. This counting process continues until the counter first decreases from 1 to 0. From the first left curly brace after the function definition line to the right curly brace that resets the counter to zero, all code content traversed (including the two curly braces themselves and all characters and lines between them) is completely extracted and identified as the function's text.

[0083] Finally, the extracted function name is merged with the function body to form a complete function structure.

[0084] However, in scenarios where it is necessary to generate module design documents with complete technical details, function names and text alone cannot clearly show the function's interface specifications and external dependencies. In order to solve the problems of incomplete document information, poor readability, and inability to be directly used as API reference, we parse and extract metadata such as function return type and parameter details, and combine them with the relationships to generate a complete and structured design document.

[0085] Specifically, step S24 above may also include: S243: Starting from the second line of the function body, extract the content to the left of the function name to obtain the return type, and determine the specific type and return logic path of the return type based on the characteristics of the programming language type of the target code. The specific type includes one of the basic type, composite type and generic type.

[0086] The first line of the function body is the function definition line (e.g., int add(int a, int b)), from which the function name (e.g., add) is obtained.

[0087] Next, extract the return type. In the function definition line, locate the beginning of the function name. Extract all characters from the beginning of the line up to the beginning of the function name. For example, in `int add(int a, int b)`, the `int` to the left of the function name `add` is the return type.

[0088] Next, parsing and classification. The extracted string is normalized (extra whitespace is removed) and parsed based on the type system rules of the target programming language. Specifically, the string is compared with the language's basic type keywords (such as int, float, void) to determine the basic type. If the string contains compound structure pointers (such as * pointer, & reference, [] array, struct, class, etc.), it is classified as a compound type. For languages ​​that support generics (such as Java, C++, C#), if the string contains generic parameters (such as List...), it is classified as a generic type. <string>If the condition is true, it is classified as generic. Furthermore, the return statement within the function body is analyzed to determine the return logic path. For example, identifying return conditions (if...return), multi-branch return paths, or paths where exceptions are thrown.

[0089] S244: Extract the parameter string between the left and right parentheses, and identify the data type and variable name of the parameter from the parameter string.

[0090] First, locate the parameter list area. In the function definition line, locate the positions of the left parenthesis (and right parenthesis). Then, extract the parameter string. Extract all characters between the parentheses (and parentheses) (e.g., int a, char* b). Finally, split and parse individual parameters. Split the parameter string into multiple substrings by commas (e.g., ["int a", "char* b"]). For each substring, remove leading and trailing whitespace and parse it based on the language-specific parameter declaration syntax. Specifically, separate the variable name and type declaration from right to left or by pattern matching. For example, in int a, a is the variable name and int is the type; in const char* ptr, ptr is the variable name and const char* is the type. Handle any modifiers (e.g., const, volatile), default values ​​(e.g., int value = 0), etc. Save the data type and variable name of each parsed parameter to a structured list (e.g., a parameters array).

[0091] At this point, all the detailed information about the function structure has been identified. Next, we can determine whether each candidate variable is a global variable based on the function structure.

[0092] When identifying global variables, for each candidate variable, the following checks are performed: First, position check. The position of the candidate variable in the code text is checked to see if it is outside the body of any already identified function structure. If it is outside a function, proceed to the next step. Second, character context check. The next character immediately following the candidate variable (ignoring whitespace) is checked to see if it is a left parenthesis "(". If it is not a left parenthesis, the possibility of it being a function name is ruled out. Candidate variables that satisfy both of these conditions are ultimately determined to be global variables.

[0093] S25: Compare the identifiers in each function structure with global variables in parallel, and compare the identifiers before the left parenthesis in each function structure with the function names of other function structures in parallel, and associate the global variables and / or function names that match the comparison with the corresponding function structures. The other function structures are the function structures in each function structure excluding the current function structure.

[0094] Step S25 here is implemented in the same way as step S14 in the previous embodiment. Please refer to the relevant description in the previous embodiment. It will not be repeated here.

[0095] S26: Based on each function name and its corresponding return type, start and end line numbers, parameter data types and variable names, as well as its associated global variables and / or function names, generate and output a target module design document in a preset format.

[0096] The generated document can be a structured DOCX file containing a cover, table of contents, a function statistics overview, a detailed list of functions grouped by file or logic (each item includes its name, return type, start and end line numbers, parameter table, global variable dependency list, and internal reference function list), and optionally includes a comparison section of differences between versions, ultimately forming a standardized software design document that can be directly used for development, auditing, or release.

[0097] However, in scenarios with complex module structures and intertwined function call relationships, it is difficult to intuitively grasp the overall logical structure of a module using only a text list. To address the issues of insufficient visualization of module architecture, difficulty in understanding dependencies, and low efficiency in design review, a call relationship graph is generated and integrated into the design document.

[0098] Specifically, step S26 above may include: S261: Generate a call graph based on each function structure and its associated global variables and / or function names.

[0099] Specifically, it iterates through all parsed function structures. For each function, it constructs directed edges using the names of associated functions recorded in its called function list. The starting point of each edge is the current function, and the ending point is every function it calls. Simultaneously, the dependencies of functions on the global variable list are visualized as special edges pointing from function nodes to global variable nodes. All functions and global variables serve as nodes, and calls and dependencies as edges, collectively forming a directed graph data model. Then, a visualization engine is invoked, and based on a preset layout algorithm (such as hierarchical layout or force-directed layout), this data model is rendered into an image or an interactive chart—a call relationship graph.

[0100] S262: Generate and output a target module design document in a preset format that includes a call relationship graph.

[0101] Specifically, following the preset DOCX template, you can first generate a cover, table of contents, and a function statistics overview section. In the function details section, in addition to listing the basic information, parameter table, global variable dependency list, and internal reference function list for each function, you can also insert or link the generated call relationship graph image at appropriate locations in the document (such as after the function overview or in the appendix).

[0102] If multi-version analysis was performed, a section comparing version differences would also be included. This section would not only use text and colors to mark the differences, but might also include comparative diagrams showing changes in call relationships between versions. Finally, all content would be integrated and saved as a complete DOCX document. This document would not only contain structured text information, but also integrate an intuitive architecture visualization view, forming a comprehensive and easy-to-understand target module design document.

[0103] S27: Compare different module design documents according to function name, return type, start and end line numbers, parameter data types and variable names, involved global variables, and called function names; generate a difference report based on the differences between the current version of the target code and the previous version of the target code in function name, return type, start and end line numbers, parameter data types and variable names, involved global variables, and called function names.

[0104] First, the structured data corresponding to the module design documents of the baseline and target versions is obtained, namely two sets of fully parsed and associated FunctionDetail structure lists. Matching is performed by function name; for functions with the same name in both versions, their return type, start and end line numbers, parameter lists (comparing the data type and variable name of each parameter), lists of involved global variables, and lists of called function names are compared one by one. Functions that exist only in one version (added or deleted) are also marked. All differences found (including changes in values ​​and additions or deletions to lists) are captured and categorized. Finally, this structured difference information is organized according to a preset report template to generate a complete difference report.

[0105] A difference report is a structured, visual document section or standalone file. Specifically, the report includes a separate section or heading titled "Version Difference Comparison." In this section, the differences are clearly categorized. Newly added functions are highlighted in green text and their complete function information is displayed. Deleted functions are highlighted in red text with strikethrough, typically showing their basic information for traceability. For functions that have been modified, specific changes are highlighted or marked in yellow according to the difference dimensions (such as parameter changes, changes in global variable dependencies, updates to call relationships, etc.). This visual presentation through color, style, and structured categorization makes the code change history and scope of impact readily apparent, greatly improving the report's readability and usability.

[0106] S28: Receive a version of the target code specified from different versions of the target code; obtain the module design document corresponding to the specified target code; obtain the difference report between the specified target code and its previous version of the target code; in the obtained module design document, mark it based on the obtained difference report to obtain the final module design document of the specified target code.

[0107] In software development and maintenance, it's often necessary to generate or review design documents for specific, outdated code versions. For example, when investigating defects introduced in historical versions, it's necessary to generate and analyze the design document corresponding to the affected version. Alternatively, after releasing a stable version (such as V2.1), a formal API manual needs to be generated. In these cases, users can explicitly select a specific version identifier from the version history, allowing the system to retrieve the target code for that specified version and generate module design documents. This fulfills the needs for archiving, auditing, and troubleshooting historical code.

[0108] When generating the final module design document, the complete content of the module design document generated for the specified version is first obtained. Then, the difference report generated by comparing the current version with its direct predecessor is read. Next, a first-level heading section named "Version Difference Comparison" is inserted into the document. Within this section, the difference content is merged into the main content of the document according to the classification of the difference report.

[0109] Specifically, for newly added functions, in addition to the regular information, the function details section can use a green background or font color to highlight all the information of the function, so as to visually indicate that it is a new addition.

[0110] For deleted functions, insert a basic information entry in red font with a strikethrough at the original location to indicate that the function no longer exists in the current version.

[0111] For functions that have been modified, the specific fields that have changed can be highlighted in yellow in the function details section. For example, parameter names and types that have changed in the parameter list can be highlighted with a yellow background, or the names of newly added called functions in the function call list can be highlighted in yellow.

[0112] In this way, the final module design document not only contains complete design information for the current version, but also seamlessly integrates a comparison of changes with the previous version, making the evolution history of the code clear at a glance.

[0113] This concludes the description of the code-based module design document generation method provided in this application embodiment.

[0114] Based on the same inventive concept, embodiments of this application also provide a code-based module design document generation device.

[0115] Figure 3 This is a schematic diagram of the structure of the code-based module design document generation device in the embodiments of this application. Figure 1 See Figure 3 As shown, the device may include: Module 31 is used to obtain the target code.

[0116] Preprocessing module 32 is used to remove compiler directives and comments from the target code to obtain the code text.

[0117] The identification and extraction module 33 is used to identify and extract global variables and function structures from code text.

[0118] The deep parsing module 34 is used to compare the identifiers in each function structure with global variables in parallel, and to compare the identifiers before the left parenthesis in each function structure with the function names of other function structures in parallel, and to associate the global variables and / or function names that match the comparison with the corresponding function structures. The other function structures are the function structures in each function structure excluding the current function structure.

[0119] Output module 35 is used to generate and output a target module design document in a preset format based on each function structure and its associated global variables and / or function names.

[0120] Furthermore, as a response to Figure 3 In addition to the refinement and expansion of the illustrated device, this application embodiment also provides a code-based module design document generation device.

[0121] Figure 4 This is a schematic diagram of the structure of the code-based module design document generation device in the embodiments of this application. Figure 2 See Figure 4 As shown, the device may include: Module 41 is used to obtain the target code.

[0122] Language recognition module 42 is used to identify the programming language type of the target code.

[0123] The preprocessing module 43 is used to remove comments from the target code based on the programming language type to obtain the first intermediate text; remove macro definitions from the first intermediate text to obtain the second intermediate text; and remove alternative branch conditions from the second intermediate text to obtain the code text.

[0124] The identification and extraction module 44 is used to identify non-identifier character sequences outside the keyword set from the code text based on the programming language type to obtain candidate variables. The keyword set includes keywords corresponding to the programming language. It also identifies function structures from the code text. If a candidate variable is located outside the function structure and the next character of the candidate variable in the code text is not a left parenthesis, then the candidate variable is determined to be a global variable.

[0125] The identification and extraction module 44 is specifically used to traverse each line of the code text in parallel. If a left parenthesis exists, it backtracks to the left and extracts the identifier before the space or operator to obtain the function name. In the code text, it traverses from the function name. If a left parenthesis is encountered, it controls the counter to increment by 1. If a right parenthesis is encountered, it controls the counter to decrement by 1 and obtains the traversal content from 1 to 0. The traversal content is determined as the function text.

[0126] The identification and extraction module 44 is also used to extract the content to the left of the function name starting from the second line of the function body, obtain the return type, and determine the specific type and return logic path of the return type based on the characteristics of the programming language type of the target code. The specific type includes one of basic type, composite type and generic type; extract the parameter string between the left parenthesis and the right parenthesis, and identify the data type and variable name of the parameter from the parameter string.

[0127] The deep parsing module 45 is used to compare the identifiers in each function structure with global variables in parallel, and to compare the identifiers before the left parenthesis in each function structure with the function names of other function structures in parallel, and to associate the global variables and / or function names that match the comparison with the corresponding function structures. The other function structures are the function structures in each function structure other than the current function structure.

[0128] Output module 46 is used to generate and output a target module design document in a preset format based on each function name and its corresponding return type, start and end line numbers, parameter data types and variable names, as well as its associated global variables and / or function names.

[0129] Output module 46 is specifically used to generate a call relationship graph based on each function structure and its associated global variables and / or function names; and to generate and output a target module design document containing the call relationship graph in a preset format.

[0130] Given that the target module design document includes module design documents corresponding to different versions of the target code, and each module design document includes a function name and its corresponding return type, start and end line numbers, parameter data types and variable names, involved global variables, and called function names, output module 46 is generated. It is also used to compare different module design documents according to function names, return types, start and end line numbers, parameter data types and variable names, involved global variables, and called function names. Based on the differences between the current version of the target code and the previous version of the target code in terms of function names, return types, start and end line numbers, parameter data types and variable names, involved global variables, and called function names, a difference report is generated.

[0131] The output generation module 46 is also used to receive a version of the target code specified from different versions of the target code; obtain the module design document corresponding to the specified target code; obtain the difference report between the specified target code and its previous version of the target code; and mark the obtained module design document based on the obtained difference report to obtain the final module design document of the specified target code.

[0132] It should be noted that the description of the above device embodiments is similar to the description of the above method embodiments, and has similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0133] Based on the same inventive concept, this application also provides a computer device.

[0134] Figure 5 This is a schematic diagram of the structure of the computer device in an embodiment of this application. See also... Figure 5 As shown, the computer device may include: a memory 51, a processor 52, and a computer program stored on the memory 51, wherein the processor 52 executes the computer program to implement the methods described in the foregoing embodiments.

[0135] It should be noted that the description of the above computer device embodiments is similar to the description of the above method embodiments, and has similar beneficial effects. For technical details not disclosed in the computer device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0136] Based on the same inventive concept, embodiments of this application also provide a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the methods described in the foregoing embodiments.

[0137] It should be noted that the description of the above computer-readable storage medium embodiments is similar to the description of the above method embodiments, and has similar beneficial effects. For technical details not disclosed in the computer-readable storage medium embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0138] Based on the same inventive concept, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the methods described in the foregoing embodiments.

[0139] It should be noted that the descriptions of the above computer program product embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the computer program product embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0140] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.< / string>

Claims

1. A method for generating code-based module design documents, characterized in that, The method includes: Obtain the target code; Remove the compiler directives and comments from the target code to obtain the code text; Identify and extract global variables and function structures from the code text; The identifiers in each function structure are compared in parallel with the global variables, and the identifiers before the left parenthesis in each function structure are compared in parallel with the function names of other function structures. Global variables and / or function names that match the comparison are associated with the corresponding function structures, wherein the other function structures are the function structures in each function structure excluding the current function structure. Based on each function structure and its associated global variables and / or function names, generate and output a target module design document in a preset format.

2. The method according to claim 1, characterized in that, The step of identifying and extracting global variables and function structures from the code text includes: From the code text, identify non-identifier character sequences outside the keyword set to obtain candidate variables, wherein the keyword set includes keywords corresponding to the programming language; Identify the function structure from the code text; If the candidate variable is located outside the function structure body, and the next character of the candidate variable in the code text is not a left parenthesis, then the candidate variable is determined to be a global variable.

3. The method according to claim 2, characterized in that, The process of identifying the function structure from the code text includes: For each line in the code text, iterate in parallel. If a left parenthesis exists, backtrack to the left and extract the identifier before the space or operator to obtain the function name. In the code text, starting from the function name, the system traverses the code. If a left parenthesis is encountered, the counter is incremented by 1. If a right parenthesis is encountered, the counter is decremented by 1. The traversal content from 1 to 0 is obtained, and the traversal content is determined as the function text.

4. The method according to claim 3, characterized in that, After determining the traversed content as the function body, the method further includes: Starting from the second line of the function body, extract the content to the left of the function name to obtain the return type, and determine the specific type and return logic path of the return type based on the characteristics of the programming language type of the target code. The specific type includes one of basic type, composite type and generic type. Extract the parameter string between the left and right parentheses, and identify the data type and variable name of the parameter from the parameter string; The process of generating and outputting a target module design document in a preset format based on each function structure and its associated global variables and / or function names includes: Based on each function name and its corresponding return type, start and end line numbers, parameter data types and variable names, as well as its associated global variables and / or function names, generate and output a target module design document in a preset format.

5. The method according to claim 1, characterized in that, The step of deleting the compiler directives and comments in the target code to obtain the code text includes: Remove the comments from the target code to obtain the first intermediate text; Delete the macro definitions in the first intermediate text to obtain the second intermediate text; Delete the alternative branch conditions in the second intermediate text to obtain the code text.

6. The method according to claim 1, characterized in that, Before removing compiler directives and comments from the target code, the method further includes: Identify the programming language type of the target code; The deletion of compiler directives and comments in the target code includes: Based on the programming language type, remove the compiler directives and comments from the target code; The step of identifying and extracting global variables and function structures from the code text includes: Based on the programming language type, global variables and function structures are identified and extracted from the code text.

7. The method according to any one of claims 1 to 6, characterized in that, The process of generating and outputting a target module design document in a preset format based on each function structure and its associated global variables and / or function names includes: Generate a call relationship graph based on each function structure and its associated global variables and / or function names; Generate and output a target module design document in a preset format that includes the call relationship graph.

8. The method according to any one of claims 1 to 6, characterized in that, The target module design document includes module design documents corresponding to different versions of the target code. The module design document includes each function name and its corresponding return type, start and end line numbers, data type and variable name of the parameters, global variables involved, and the name of the function called. After generating and outputting the target module design document in a preset format, the method further includes: The different module design documents are compared according to function name, return type, start and end line numbers, parameter data type and variable name, global variables involved, and function name called; A difference report is generated based on the differences between the current version of the target code and the previous version in function names, return types, start and end line numbers, parameter data types and variable names, global variables involved, and function names called.

9. The method according to claim 8, characterized in that, After generating the difference report, the method further includes: Receives a version of the object code specified from different versions of the object code; Retrieve the module design document corresponding to the specified target code; Retrieve a difference report between the specified target code and its previous version; In the obtained module design document, markings are made based on the obtained difference report to obtain the final module design document of the specified target code.

10. A device for generating code-based module design documents, characterized in that, The device includes: The acquisition module is used to acquire the target code; The preprocessing module is used to remove compiler directives and comments from the target code to obtain the code text; The identification and extraction module is used to identify and extract global variables and function structures from the code text; The deep parsing module is used to compare the identifiers in each function structure with the global variables in parallel, and to compare the identifiers before the left parenthesis in each function structure with the function names of other function structures in parallel, and to associate the global variables and / or function names that match the comparison with the corresponding function structures, wherein the other function structures are the function structures in each function structure excluding the current function structure; The output generation module is used to generate and output a target module design document in a preset format based on each function structure and its associated global variables and / or function names.

Images