Code file analysis method and device and nonvolatile storage medium

Abstract

The application discloses a code file analysis method and device and a nonvolatile storage medium. The method comprises the following steps: receiving a code file to be identified; traversing the code file to identify a valid statement set in the code file, wherein the valid statement set comprises statements other than code comment statements in the code file; identifying an identifier segment of each statement in the valid statement set, wherein the identifier segment is determined according to a plurality of characters defined in advance; determining a target identifier segment that satisfies a preset function judgment rule from the identifier segment, determining the target identifier segment as a target function to be called, and determining the position of the target identifier segment in the code file as the position of the target function. The application solves the technical problems of low function positioning efficiency and low accuracy caused by relying only on manual retrieval to extract the specific position of the function in the code in the related art.

Description

Technical Field

[0001] This application relates to the field of computers, and more specifically, to a method, apparatus, and non-volatile storage medium for analyzing code files. Background Technology

[0002] With the continuous development of software technology, the scale and complexity of software are also increasing. Especially with the rise of the open-source movement, a large amount of code is shared through open-source platforms, leading to a significant increase in the number of software developers. However, this rapid increase in code volume makes code maintenance increasingly difficult, particularly when encountering software errors, as locating the function where the error occurred is not easy. Therefore, how to efficiently locate functions in the code is a pressing problem that needs to be solved.

[0003] Function location is usually based on the syntax analysis of the source code file. The source code is traversed to determine the location of the function. In related technologies, function location requires manual browsing of the entire code file and syntax analysis. Users need to manually enter the name of the function to be located to search for the function. Furthermore, it is not possible to perform structural analysis and extraction of complex or long functions. The efficiency and accuracy of function structure analysis and extraction are low.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a method, apparatus, and non-volatile storage medium for analyzing code files, to at least solve the technical problem in related technologies where extracting the specific location of functions in code relies solely on manual retrieval, resulting in low efficiency and low accuracy in function location.

[0006] According to one aspect of the embodiments of this application, a method for analyzing code files is provided, comprising: receiving a code file to be identified; traversing the code file to identify a set of valid statements in the code file, wherein the set of valid statements includes statements other than code comment statements in the code file; identifying an identifier segment for each statement in the set of valid statements, wherein the identifier segment is determined based on a plurality of predefined characters; determining a target identifier segment from the identifier segments that satisfies a preset function determination rule, and determining the target identifier segment as the target function to be called, and determining the position of the target identifier segment in the code file as the position of the target function.

[0007] According to some embodiments of this application, determining a target identifier segment that satisfies a preset function determination rule from an identifier segment includes: verifying a first type of identifier segment in a first manner to obtain a target identifier segment, wherein the first type of identifier segment is an identifier segment that satisfies the preset code environment requirements in the preset function determination rule, and the first manner is a preset function identification method corresponding to the preset code environment requirements.

[0008] According to some embodiments of this application, determining a target identifier segment that satisfies a preset function determination rule from an identifier segment includes: verifying a second type of identifier segment in a second manner to obtain a target identifier segment, wherein the second type of identifier segment is an identifier segment other than the first type of identifier segment, and the second manner is a function identification method predefined in the preset function determination rule for the second type of identifier segment.

[0009] According to some embodiments of this application, a first type of identifier segment is verified to obtain a target identifier segment in a first manner, including: determining a scope as a character region in each first type of identifier segment that starts with a first preset keyword and ends with a second preset keyword, wherein the first preset keyword is used to define a function and the second preset keyword is used to indicate the end of the function; for each scope, removing characters that match the character names in the preset variable declaration list to obtain an initial target identifier segment, wherein each scope corresponds to a preset variable declaration list; and determining the initial target identifier segment that does not belong to the function call context as the target identifier segment.

[0010] According to some embodiments of this application, the second type of identifier segment is verified in a second way to obtain the target identifier segment, including: the second type of identifier segment is determined to be the target identifier segment when the following conditions are met simultaneously: the second type of identifier segment does not start with a number; the second type of identifier segment does not belong to the preset global variable or preset function character declared in the code file; the second type of identifier segment does not belong to the preset variable declared in the statement corresponding to the second type of identifier segment.

[0011] According to some embodiments of this application, the method further includes: forming a target function set by assembling all target functions determined based on all identifier fields in the valid statement set; determining the function call relationship between each target function in the target function set based on a preset script file, wherein the preset script file is used to indicate all function names contained in the code file; and constructing a function call tree based on the function call relationship and the target function set, wherein the function call tree is used to indicate the call path and hierarchical relationship between each target function.

[0012] According to some embodiments of this application, the code file to be identified includes a class definition file. The method further includes: identifying a first field and a second field belonging to a first preset format from the identifier field of the class definition file, and identifying a preset symbol from the class definition file; identifying a target field conforming to a second preset format from the class definition file, the second preset format including the following sequential arrangement: first field, preset symbol, second field; if it is determined that the target field is not a variable declaration and the first field is a declared variable, determining a first function defining the first field and determining the category of the first function; if the category of the first function is the same as the name of any defined class, determining the defined class with the same name as the target class, and determining that the first field is an object of the target class, the target field being the field to be called.

[0013] According to some embodiments of this application, the code file to be identified includes a class definition file. The method further includes: identifying a first field and a second field belonging to a first preset format from the identifier field of the class definition file, and identifying a preset symbol from the class definition file; identifying a target field conforming to a second preset format from the class definition file, the second preset format including the following sequential arrangement: first field, preset symbol, second field; and, if the target field is determined to be a declared variable, determining that the target field is not a field to be called, and storing the target field as a variable.

[0014] According to some embodiments of this application, the code file to be identified includes a class definition file. The method further includes: identifying a first field and a second field belonging to a first preset format from the identifier field of the class definition file, and identifying a preset symbol from the class definition file; identifying a target field conforming to a second preset format from the class definition file, the second preset format including the following order: first field, preset symbol, second field; and determining that the first field is a class name and the target field is a field called based on the class name when it is determined that the target field is not a variable declaration and the first field is not a declared variable.

[0015] According to some embodiments of this application, the code file to be identified includes a class definition file. The method further includes: identifying a first field and a second field belonging to a first preset format from the identifier field of the class definition file, and identifying a preset symbol from the class definition file; identifying a target field conforming to a second preset format from the class definition file, the second preset format including the following sequential arrangement: the first field, the preset symbol, and the second field; when it is determined that the target field is not a variable declaration, the first field is a declared variable, and the first function defining the first field cannot be determined or the first function defining the first field is determined, and the category of the first function is different from the name of any defined class, the first field is determined to be an undefined class or a directly input variable.

[0016] According to another aspect of the embodiments of this application, a code file analysis apparatus is also provided, comprising: a receiving module for receiving a code file to be identified; a first identification module for traversing the code file and identifying a set of valid statements in the code file, wherein the set of valid statements includes statements in the code file excluding code comment statements; a second identification module for identifying an identifier segment of each statement in the set of valid statements, wherein the identifier segment is determined based on a plurality of predefined characters; and a determining module for determining a target identifier segment from the identifier segments that satisfies a preset function determination rule, determining the target identifier segment as the target function to be called, and determining the position of the target identifier segment in the code file as the position of the target function.

[0017] According to another aspect of the embodiments of this application, a non-volatile storage medium is also provided, in which a program is stored, wherein the program, when running, controls the device where the non-volatile storage medium is located to execute the above-mentioned code file analysis method.

[0018] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory and a processor, wherein the processor is used to run a program stored in the memory, wherein the program executes the above-described code file analysis method when it runs.

[0019] According to another aspect of the embodiments of this application, a computer program product is also provided, including computer instructions, and an analysis method for the above-described code file is provided when the computer instructions are executed by a processor.

[0020] In this embodiment, the method involves receiving a code file to be identified; traversing the code file to identify a set of valid statements, including statements other than code comments; identifying the identifier segment of each statement in the set of valid statements, where the identifier segment is determined based on multiple predefined characters; determining the target identifier segment that satisfies a preset function determination rule from the identifier segments, and identifying the target identifier segment as the target function to be called; and determining the position of the target identifier segment in the code file as the position of the target function. By identifying the set of valid statements in the code file, then identifying the identifier segment and non-identifier segments of each statement in the set of valid statements, and finally determining the target identifier segment belonging to the function in the identifier segments according to the preset function determination rule, the method achieves the goal of directly determining the specific position of the function through the preset function determination rule, improving the efficiency and accuracy of function location, and thus solving the technical problem of low efficiency and low accuracy of function location caused by relying solely on manual retrieval when extracting the specific position of a function in the code in related technologies. Attached Figure Description

[0021] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0022] Figure 1 This is a hardware structure block diagram of a computer terminal for implementing a code file analysis method according to an embodiment of this application;

[0023] Figure 2 This is a flowchart of a code file analysis method provided according to an embodiment of this application;

[0024] Figure 3 This is a flowchart illustrating the processing of a class definition file according to an embodiment of this application;

[0025] Figure 4 This is a flowchart of another code file analysis method provided according to an embodiment of this application;

[0026] Figure 5 This is a schematic diagram of a code file analysis device provided according to an embodiment of this application. Detailed Implementation

[0027] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0028] The information collected in this application embodiment is information and data authorized by the user or fully authorized by all parties. The collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with the relevant laws, regulations and standards of the relevant regions, and necessary confidentiality measures have been taken. It does not violate public order and good morals, and provides corresponding operation entry points for users to choose to authorize or reject the automated decision results. If the user chooses to reject, the process will proceed to the expert decision-making process.

[0029] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0030] In related technologies, function location is typically based on the syntax analysis of source code files, traversing the source code to determine the location of functions. However, this method relies on manual browsing of the entire code file for syntax analysis, and users must manually input the function name to search for it. Furthermore, it cannot perform structural analysis and extraction for complex or long functions. Therefore, the reliance on manual retrieval for extracting the specific location of functions in the code results in low efficiency and accuracy in function location. To address this issue, this application provides a solution, which is detailed below.

[0031] According to an embodiment of this application, an embodiment of a method for analyzing code files is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0032] The methods and embodiments provided in this application can be executed on a computer terminal or similar computing device. Figure 1 A hardware block diagram of a computer terminal for implementing a code file analysis method is shown. Figure 1 As shown, the computer terminal 10 may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0033] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10. As involved in the embodiments of this application, the data processing circuits serve as a form of processor control (e.g., selection of a variable resistor termination path connected to an interface).

[0034] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the code file analysis method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the above-mentioned code file analysis method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0035] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0036] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10.

[0037] In the above operating environment, this application provides an embodiment of a code file analysis method. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0038] like Figure 2 The diagram shown is a flowchart of a code file analysis method provided according to an embodiment of this application, including:

[0039] Step S202: Receive the code file to be identified.

[0040] In the technical solution provided in step S202, the initialization phase of the identification process involves receiving the code file to be identified input by the user. This step is the starting point of the entire code file analysis process, defining the specific goals of subsequent analysis. The code file can be any script or function file, or a class definition file, containing the code used by the developer to implement specific functions. Users can upload code files in various ways, such as selecting a file in the plugin's interface or directly entering the file path in the command line. The code file is the raw data for analysis, containing a large number of function calls, variable declarations, operational expressions, and syntactic structures.

[0041] Step S204: Traverse the code file and identify the set of valid statements in the code file.

[0042] In the technical solution provided in step S204, the set of valid statements includes statements in the code file excluding code comment statements. This process aims to remove comments and other non-functional text from the code file, leaving directly executable code statements, thus laying the foundation for subsequent function call analysis.

[0043] As some embodiments of this application:

[0044] First, the code file received in step S202 is read and converted into text format. Next, preprocessing is performed, including removing multi-line comments, single-line comments, and blank lines and whitespace characters to simplify the subsequent statement recognition process. After removing the above content, a set of valid statements is obtained. Different comment statement rules are determined according to the code rules of different programming languages ​​and the code rules of user-defined languages ​​or extended languages. The system used for function recognition in this application is configured with a comment statement rule determination template. The template is pre-configured with different comment statement rules, which can be directly adapted to the code file during use. During preprocessing, comment statements are filtered according to the comment statement rules corresponding to the programming language of the code file. For example, if the comment statement rules for a code file define text starting with a percent sign to the end of the line as a comment, and the code file is written in C / C++ or Java, then the corresponding comment statement rules indicate that text starting with / / to the end of the line is considered a single-line comment, and text enclosed by / and / is considered a multi-line comment.

[0045] Step S206: Identify the identifier segment of each statement in the set of valid statements, wherein the identifier segment is determined based on a plurality of predefined characters.

[0046] In the technical solution provided in step S206, there are multiple ways to identify the identifier segment and non-identifier segment of each statement in the set of valid statements. For example, a continuous character sequence composed of the predefined multiple characters in the set of valid statements can be identified as an identifier segment; a continuous character sequence composed of characters other than the identifier segment in the set of valid statements can be identified as a non-identifier segment. The predefined multiple characters include at least letters, numbers, and underscores. It should be noted that the identification of the identifier segment is illustrated using a code language where letters, numbers, and underscores are identified as identifiers. The predefined multiple characters are pre-set according to the syntax characteristics indicated by the configuration information of the code language. For different programming languages, corresponding predefined multiple characters are pre-set. Therefore, for different code files, the predefined multiple characters can be adjusted according to the configuration information of the code file to adapt to different code files written in different programming languages.

[0047] As some embodiments of this application:

[0048] Every programming language's code consists of identifiers and non-identifiers. Identifiers are used to name variables, functions, classes, or other user-defined entities, and also to generate logical structures. Non-identifiers handle operations, comments, and other special functions. All code is composed of alternating identifier and non-identifier segments. When identifying the identifier and non-identifier segments of each statement in the set of valid statements, an initial state, such as a "searching for identifiers" state, and a temporary buffer are set to store the currently identified segment. Each character in each valid statement is traversed, and based on the current state and the character's nature (i.e., whether it belongs to a predefined set of characters), it is determined whether it is an identifier or a non-identifier. When the first character belonging to a predefined set of characters is encountered, the system (referring to the system used for function identification, hereinafter referred to as the system) enters the "identifier" state and adds the character to the buffer. Character traversal continues; if subsequent characters belong to a predefined set of characters, the system remains in the "identifier" state. Once a character not belonging to a predefined set of characters, such as an operator, parentheses, or a space, is encountered, the system exits the "identifier" state. At this point, the contents of the buffer are treated as a complete identifier segment and recorded. When the system is not in the "identifier" state, any character encountered is considered part of the non-identifier segment until a new identifier segment is encountered. During traversal, the system switches between "identifier" and "non-identifier" states depending on the nature of the encountered characters. Each state switch triggers a command to record the current buffer contents, i.e., the identifier segment or the non-identifier segment. Each pair of statements in the code is separated by a semicolon or a newline character. The above steps are repeated until all valid statements have been traversed and subdivided, identifying the identifier and non-identifier segments for each statement in the valid statement set. For example, for the statement: C = D(10, 5); in this example, the letter C is first traversed and identified as an identifier segment; then the "=" is read and identified as a non-identifier segment; then the letter D is encountered and identified as an identifier segment again, and so on, until the end of the statement. By accurately distinguishing between identifier and non-identifier segments, this method can more accurately identify function calls, avoiding misidentification of non-function call identifiers as functions, thereby improving the accuracy of function location.

[0049] Step S208: Determine the target identifier segment that meets the preset function determination rules from the identifier segment, and determine the target identifier segment as the target function to be called, and determine the position of the target identifier segment in the code file as the position of the target function.

[0050] In the technical solution provided in step S208, there are multiple ways to determine the target identifier segment that satisfies the preset function determination rule from the identifier segment, for example:

[0051] The first method verifies the first type of identifier segment to obtain the target identifier segment. The first type of identifier segment is one that meets the preset code environment requirements in the preset function determination rules, and the first method is the preset function identification method corresponding to the preset code environment requirements. Through this first method, the method can accurately identify function calls based on the preset code environment requirements, avoiding misidentification of non-function call identifiers as function calls, thereby improving the accuracy and efficiency of function location. The preset function determination rules are a set of conditions and standards used to determine whether an identifier segment represents a function call. These rules are determined based on the syntactic characteristics of different programming languages. The preset function identification rules include, but are not limited to: keyword location rules (including the definition of the first and second preset keywords), identifier segment and non-identifier segment identification rules (i.e., step S206 above), function call context rules (used to check whether the identifier segment is in a call context, such as whether there are parentheses immediately following the identifier; analyzing the context of function calls, such as chained calls), scope rules (defining the scope of local variables, global variables, and class members to ensure correct identification of function calls rather than other types of identifier references), function handle and string rules (used to parse function handles, distinguish function name references in strings, and prevent mistaking text within strings for actual function calls), preset environment rules (different programming languages ​​have different syntax and conventions. By setting preset environment rules specific to different programming language environments, the accuracy and efficiency of function call identification can be improved), etc., ensuring that function calls can be accurately identified when processing any given code file, while avoiding identification errors and omissions, providing a solid foundation for code structure analysis and function call extraction.

[0052] The first method verifies the first type of identifier segment, revealing several implementation methods for the target identifier segment. For example, the character region within each first type of identifier segment, starting with a first preset keyword and ending with a second preset keyword, is defined as a scope. The first preset keyword defines a function, and the second preset keyword indicates the end of the function. For each scope, characters matching the names in the preset variable declaration list are removed to obtain the initial target identifier segment, where each scope corresponds to a preset variable declaration list. Initial target identifier segments that do not belong to the function call context are then identified as target identifier segments. The function call context refers to the specific environment and conditions in which a function call occurs; it involves how the function call interacts with surrounding code, as well as the purpose and expected result of the function call. The concept of scope is used in programming to limit the visibility of identifiers. For example, in C, {} defines the scope of a function body. By determining the scope, this method can identify local variables within a function, avoiding misinterpreting these local variables as function calls.

[0053] The following are specific examples:

[0054] Step S208 further filters all identifier segments identified in step S206 to determine which identifier segments represent function calls. This step involves identifying the function call context and excluding identifier segments that are not part of the function call context, such as variable declarations. In the code, besides explicitly defined functions, there are also library function calls, macro definitions, etc. The first method can identify these special function calls, ensuring comprehensive function location. For example, specific preprocessor directives are required to identify macro definitions.

[0055] The first type of identifier segment consists of identifier segments that meet the preset code environment requirements in the preset function determination rules. The preset code environment requirements are function environments (e.g., `function`) and special environments (e.g., non-identifier-guided environments such as strings and function handles). Identifying function environments guided by the `function` keyword can be achieved by checking whether there are function definitions and termination patterns conforming to the standard format of function declarations before and after the identifier segment containing the `function` keyword. For non-identifier-guided environments such as strings and function handles, additional marking or processing is performed during analysis. For example, when encountering a non-identifier-guided environment of type string, the system enters the string environment state (any identifiers encountered during this period are not considered function calls); when encountering a function handle-guided environment, the system enters the function handle environment state (identifier segments in this environment represent the creation of function handles, not ordinary function calls). After identifying all first-type identifier segments under the above preset code environment requirements, each first-type identifier segment is checked to see if it is located in a valid function environment (e.g., `function`) or a special environment. In special environments, such as strings and function handles, even if the identifier looks like a function, it should not be considered a function call. Within a function environment, the character region in each first-class identifier segment, starting with a first preset keyword (e.g., the `function` keyword) and ending with a second preset keyword (e.g., the `end` keyword), is defined as a scope. After confirming the start and end points of the function environment, the algorithm can focus on analyzing this scope, identifying variable declarations, function calls, and other structures (including identifying local variables, parameters, and other functions called within the function). For each scope, characters matching names in the preset variable declaration list are removed to obtain the initial target identifier segments. Each scope corresponds to a preset variable declaration list (containing all variable names within that scope). Initial target identifier segments not belonging to the function call context are defined as target identifier segments. Within each scope's identifier segments, all identifier segments matching names in the scope's variable declaration list are removed. The remaining identifier segments exclude variable declarations. Finally, the filtered identifier segments are further analyzed to determine whether they are within the function call context. For example, in sin(x) (where x represents an input value), sin is an identifier segment acting as a function call, while the letter A in the assignment statement A = B is a variable reference, not a function call. Through context analysis, we can further determine which identifier segments are target identifier segments (i.e., function calls) and record their locations in the code file.

[0056] The second type of identifier segment is verified by the second method to obtain the target identifier segment. The second type of identifier segment is an identifier segment other than the first type of identifier segment. The second method is a function recognition method for the second type of identifier segment that is predefined in the preset function judgment rules.

[0057] The second method verifies the second type of identifier segment, revealing multiple implementations of the target identifier segment. For example, a second type of identifier segment is identified as the target identifier segment when the following conditions are met: the second type of identifier segment does not begin with a number; the second type of identifier segment is not a predefined global variable or predefined function character declared in the code file; and the second type of identifier segment is not a predefined variable declared in the statement corresponding to the second type of identifier segment. In the code, global variables and predefined function characters (such as the loop keyword (for) in C) are not considered function calls. By setting these conditions, this method can exclude these non-function call identifiers, ensuring the accuracy of the target identifier segment. Conditional filtering improves the accuracy of function location and resolves the problem of confusion between global variables, predefined function characters, and function calls.

[0058] The following are specific examples:

[0059] Before processing the code, collect and record all global variables and predefined function characters (such as various keywords) declared in the code file. This can be achieved through syntax analysis or code preprocessing. Extract all Category II identifier segments from the code. First, exclude all identifier segments that begin with a number, because according to default rules, function names are not allowed to start with a number. Compare Category II identifier segments with the list of global variables and the list of predefined function characters, excluding any matching identifier segments, as they do not represent function calls. Global variables are variables that can be accessed from any part of the program. They are declared at the top of the code file or at a specific location, so any function or code segment can read and modify the values ​​of these variables during program execution. Predefined global variables (i.e., global variables) refer to variables that are predefined in the programming environment or declared as global by the user before code analysis. These variables are shared by multiple functions. Predefined function characters refer to keywords or specific symbols in the programming language. They have predefined meanings and functions used to control the logical flow of code, declare variable types, function calls, etc. During code analysis and function call identification, predefined function characters are not considered function calls. Understanding and correctly handling default global variables and default function characters is crucial when performing code structure analysis and function call identification. Default global variables are used for data sharing across functions or modules, while default function characters are a key part of the language syntax, used to control the structure and logic of the code. By excluding these elements from the candidate list for function call identification, the accuracy and efficiency of the algorithm can be ensured, false positives and confusion can be avoided, thus providing clearer code understanding and more efficient development support.

[0060] Preset variables declared in statements corresponding to the second type of identifier segment represent local variable declarations, referring to variables declared or assigned values ​​within the same statement where the second type of identifier segment appears. In most programming languages, preset variables are declared through assignment statements. In each statement, local variable declarations are identified and excluded to avoid misinterpreting local variables as function calls. Context analysis is performed on the remaining identifier segments to check if they appear in positions consistent with function call patterns, such as before parentheses or to the right of assignment statements. Identifier segments that pass the above verification steps are identified as target identifier segments (i.e., function calls, or called functions), and their specific locations in the code are recorded. Furthermore, it is possible to further identify which functions are not yet implemented in the high-performance visualization software for numerical computation using this method based on command-line analysis: using the method of this application, all identifier segments belonging to called functions are extracted from the code to obtain a function call list. A list of currently implemented functions in the high-performance visualization software for numerical computation is obtained (this can be achieved through query commands), and the function call list is compared with the function list. For each function call identifier in the list, it is checked whether the identifier exists in the list of functions already implemented by the software. If a function call exists in the list of implemented functions, it means the function call points to an implemented function. If it does not exist in the list, it means the function call points to an unimplemented function. For unimplemented functions discovered during the comparative analysis, record the name of the unimplemented function and its location in the code. This record will include information such as the filename and line number of the function call. The information about the identified unimplemented functions will be output to a log file or the console for developers' reference.

[0061] To more clearly illustrate the relationships between function calls when identifying target identifier fields (i.e., function calls), a target function set is formed by combining all target functions identified from all identifier fields in the valid statement set. The function call relationships between the target functions in the target function set are determined based on a pre-defined script file, which indicates all function names contained in the code file. A function call tree is then constructed based on the function call relationships and the target function set, indicating the call paths and hierarchical relationships between the target functions. A function call tree is a graphical tool for representing function call relationships, clearly showing the call hierarchy and paths between functions. For example, if function A calls function B, and function B calls function C, then in the function call tree, A is above B, and B is above C, forming a hierarchical call structure. This solution, by constructing a function call tree, not only accurately displays function call relationships but also helps developers understand the code execution flow, improving the efficiency of code review and debugging, and solving the problem of difficult-to-understand function call relationships caused by complex code structures.

[0062] The following are specific examples:

[0063] First, the entire codebase, i.e., a specific directory, is scanned to collect the names of all script files within the code files. Then, the identifier segments in all valid statement sets are identified as target identifier segments (i.e., function calls), and these are grouped into a target function set. The codebase is traversed again; for each script file, its internal function calls are analyzed. By comparing these function names with all function names recorded in predefined script files, the call relationships between target functions and other functions are identified, constructing a call structure. Based on the determined function call relationships and the target function set, a graphical representation (such as a tree structure) is used to construct the function call tree of the entire codebase. Nodes in the tree represent functions, edges represent call relationships, and the path from the root node to a leaf node represents the call path.

[0064] The code files to be identified include class definition files (used to define the structure and members of a class, with the filename being the same as the class name). The method described in this application can also be used to analyze object-oriented programming code, extracting members defined in a class definition file and identifying whether these classes are called in other files. For class definition files, the identifier and non-identifier segments are extracted according to steps S202-S206. Members declared in class definition files can be identified by introducing an environment stack to track the current code's environment (or scope). When a first-class keyword (used to define the environment of class members, such as the classdef keyword, properties keyword, or methods keyword) or control flow statement (e.g., if, for, etc.) is identified in the class definition file, the first-class keyword is pushed onto the environment stack. When a second-class keyword (representing the end, such as the end keyword) is encountered, an element is popped from the top of the environment stack. This ensures that the top of the environment stack always reflects the innermost code environment. This method is crucial for correctly identifying class members and understanding the context of member calls. Class members (attributes or methods) must be defined within an environment guided by the first type of keyword. For class definition files, a call tree can also be constructed. Before constructing the call tree, the entire codebase is traversed to identify all class definition files and extract their member lists (members refer to methods and properties). This process is fundamental for subsequent member call identification and call tree construction. With the class member list, all member calls are identified and recorded, and a call tree is constructed based on the relationships between member calls across all classes, where nodes represent classes or functions, and edges represent call relationships. For class member calls, the tree structure reflects the call hierarchy and dependencies between class members.

[0065] For class definition files, identifying member calls within the file (i.e., which fields in the definition file are called class members) can be done in the following ways:

[0066] From the identifier segment of the class definition file, identify the first and second fields belonging to the first preset format (the first preset format begins with a letter or underscore; the first preset format can be adapted to the syntax requirements of different programming languages). Also identify the preset symbol (the preset symbol is the period "."; the preset symbol can be adapted to the syntax requirements of different programming languages). From the class definition file, identify the target field conforming to the second preset format, which includes the following order: first field, preset symbol, second field. The target field conforming to the second preset format is the target field whose format is the first field, preset symbol, second field arranged in the order listed (also called the target character sequence). For example, "AB" (here, A and B are identifier segments beginning with a letter or underscore).

[0067] If the target field is determined to be a non-variable declaration (determined through steps S202-S208 to determine if the target field is a variable declaration, i.e., if the target field meets the preset function judgment rules, it represents a function call; if the target field does not meet the preset function judgment rules, it represents a variable declaration, and a non-variable declaration corresponds to a function call), and the first field is a declared variable (a variable that has been explicitly defined within the scope and has a specific name and type), then the first function defining the first field is determined (i.e., the function that declares the first field; backtracking the code, starting from the most recent variable assignment or declaration statement, until the function that initially declared the first field is found), and the category of the first function is determined (i.e., it is determined that the function is indeed a constructor of a class, and the function name is taken as the category of the first function); if the category of the first function is the same as the name of any defined class, the defined class with the same name is determined as the target class (the defined class with the same name as the category of the first function is determined as the target class), and the first field is determined to be an object of the target class. The target field is the called field, representing a member call of the target class. If the target class has a second field, the second field is a member of the target class (members refer to methods and properties).

[0068] If the target field is determined to be a variable declaration, and the target field is not the field being called, then the target field is stored as a variable (at this time, the first field will be used as a structure variable, in which the target field is a regular variable).

[0069] If the target field is not a variable declaration and the first field is not a declared variable, then the first field is determined to be the class name (the class name is the name that uniquely identifies a class), and the target field is the field that is called based on the class name (i.e., a member call of the class whose class name is the first field). When the first field is declared as a variable in the current scope, the first field is the class name, the second field is a member of the class corresponding to the class name, and the target field is the field that is called based on the class name, i.e., a member call of the class.

[0070] If the target field is determined to be a non-variable declaration, the first field is a declared variable, and the first function defining the first field cannot be determined, or after determining the first function defining the first field, the category of the first function is different from the name of any defined class (i.e., the first function defining the first field can be determined, but the category of the first function is different from the name of any defined class, and the first field does not directly belong to a known class), then the first field is determined to be an undefined class (a reference to a third-party library or part of the code that is still under development) or a directly input variable.

[0071] As some embodiments of this application: In a programming environment, when it is necessary to parse and extract calls to classes and their members, a systematic strategy is followed to ensure the accuracy of the analysis. Assuming `classname` is a defined class, and a member is defined in this class (named `membername`, denoted by B, i.e., the second field mentioned above), the following process details how to identify and distinguish member call methods: Class member calls mainly follow two patterns: Instance member calls: First, an instance of the class is created through the constructor of `classname` (represented by `A`, i.e., the first field mentioned above). Subsequently, the instance's member methods or attributes can be directly called through `A.membername`. Static member calls: Members are called directly through the class name `classname.membername`. This method is limited to calling members of certain categories, such as static function members. Member calls must contain the "." symbol. When a part in the form of "AB" appears in the code (A and B are identifier fields starting with a letter or underscore, B corresponding to the second field mentioned above), a preset function determination rule is used to determine whether AB (i.e., the target field mentioned above) is a variable declaration or a function call. If it is a variable declaration, and the target field is determined not to be the field being called, the target field is stored as a variable. A is treated as a structure, and the target field is its member, which is interpreted and used as a regular variable.

[0072] If the target variable is declared as a non-variable (i.e., a function call), then it's a call to a class or member. There are several types of non-variable target variable declarations: In a non-variable target variable declaration, the first field (e.g., classname, represented by A) is a declared variable. In this case, the first function defining the first field A is determined (the function defining A is the class name of A; for example, according to instance member method calls, A = classname(...) in the code indicates that the Aclassname function is defined, and the class name of A is classname). The category (i.e., function name) of the first function is also determined. If the category of the first function is the same as the name of any defined class (e.g., the name of the defined class is classname, which is the same as the name of the first function defining A, then that class is the target class), then A is an object of the target class. If the target class has a second field (e.g., the classname class has a second member field (e.g., membername, represented by B)), the second field represents a member of the target class (members refer to methods and attributes). The target field is the field being called, representing a member call of the target class (e.g., AB is a call to member B in the classname class). It's important to note that the first function defining the first field sometimes requires recursion. For example, the first field (e.g., classname, represented by A) might be defined by the function Func, and A might be defined as a certain class in the return variable of Func. If the code defining the function is available, it's necessary to trace back to the original function defining A (either a constructor of a class or a function whose source code is no longer available). If the source code cannot be found at a certain point, the class to which A belongs cannot be determined. In other words, if the first field is a declared variable and the first function defining it cannot be determined, or if the first function defining it is determined but its category is different from the name of any defined class (i.e., the first function defining the first field can be identified, but its category is different from the name of any defined class, meaning the first field does not directly belong to a known class), then the first field is determined to be an undefined class (a reference to a third-party library or part of the code still under development) or a directly input variable. If the first field (e.g., classname, denoted by A) is not a declared variable, then the first field is the class name, and the call is performed using static member invocation. In this case, the first field is determined to be the class name, and the target field is the field called based on the class name (i.e., a member call of the class whose class name is the first field). When the first field is declared as a variable within the current scope, the first field is the class name, the second field is a member of the class corresponding to the class name, and the target field is the field called based on the class name, i.e., a member call of the class.

[0073] like Figure 3The diagram shows a processing flowchart for a class definition file according to an embodiment of this application. First, the target field AB (A being the first field mentioned above, and B being the second field mentioned above) is identified. It is then determined whether AB is a function call or a variable declaration. If it is a variable declaration, both A and AB are stored as variables (i.e., if the target field is determined to be a declared variable, it is determined that the target field is not the called field, and the target field is stored as a variable). If it is a function call (i.e., not a variable declaration), it is determined whether A is an already declared variable. If A is an already declared variable, the definition function of A is traced and its category is determined. If its category is the same as the name of an already defined class, then A is an object belonging to this class, and AB is a member call of this class (i.e., if the target field is determined to be not a variable declaration and the first field is a declared variable, the first function defining the first field is determined, and the category of the first function is determined; if the category of the first function is the same as the name of any already defined class, the already defined class with the same name is determined as the target class, and the first field is determined to be an object of the target class, and the target field is the called field). If its category differs from all defined class names or cannot be traced back to a defined function, then A is either an undefined class or a directly input variable, and its class cannot be determined (i.e., when the target field is determined to be a non-variable declaration, the first field is a declared variable, and the first function defining the first field cannot be determined, or after determining the first function defining the first field, the category of the first function is different from the name of any defined class, the first field is determined to be an undefined class or a directly input variable). If A is not a declared variable, then A is a class name, and AB are members directly called based on the class name (i.e., when the target field is determined to be a non-variable declaration, and the first field is not a declared variable, the first field is determined to be the class name, and the target field is the field called based on the class name). Finally, relevant information (i.e., whether the target field is called) is recorded, and identification continues.

[0074] Through the combination of technical features in steps S202-S208 above, including the identification of valid statement sets, precise division of identifier and non-identifier segments, application of preset function judgment rules, determination of scope and conditional filtering, and construction of the function call tree, automatic and accurate function location and call relationship display are achieved. These technical features interact to solve problems such as false positives, false negatives, confusion between local variables and function calls, and confusion between global variables and function calls in function identification, significantly improving the efficiency and accuracy of code review. In the field of software development, including but not limited to game development, system software development, and application software development, the application of this method can greatly reduce the time developers spend on function location and code review, improving the overall efficiency of software development, especially when dealing with large-scale, highly complex codebases, where its advantages are even more obvious. The method of this application is applicable to the analysis of code files of high-performance visualization software that performs numerical calculations (such software can perform complex mathematical operations, data analysis, algorithm development, and visualization). The method and system of this application can be configured as a plugin for high-performance visualization software. This plugin also supports other commands, which can output results to a file or perform batch operations in a directory. It can also extract the call tree structure of large codebases, saving developers a significant amount of time and effort. The specific implementation details of each step can be adaptively modified and adapted according to the development languages ​​used by different high-performance visualization software.

[0075] This application also provides a flowchart of another method for analyzing code files, such as... Figure 4 As shown, it includes:

[0076] First, read the valid statements in the code file (i.e., traverse the code file as described above to identify the set of valid statements). Then, identify the next identifier segment of the statement and determine whether the identifier segment is in a special environment (the special environment refers to the preset code environment requirements mentioned above). For identifier segments in special environments, perform corresponding processing (i.e., verify the first type of identifier segment using the first method to obtain the target identifier segment). For identifier segments that do not belong to special environments, determine whether they start with a number. If they start with a number, it means it is not a function call. Check if the statement has ended. If it has not ended, proceed to the next identifier segment. If it starts with a number, further determine whether the identifier segment is a declared variable or a preset function word. If so, statement identification ends. If not, determine whether it is a variable declared in this statement. If it is a variable declared in this statement, it means it is not a function call, and it is recorded in the declared variable list. Check if the statement has ended. If it has not ended, proceed to the next identifier segment. If it is not a variable declared in this statement, it means the identifier segment is a called function, and it is recorded (i.e., verify the second type of identifier segment using the second method to obtain the target identifier segment). Then, it checks if the statement has ended. If the statement has not ended, it checks if the next identifier segment is a function call. If the statement has ended, it checks if the code file has ended, that is, whether all statements in the code file have been traversed. If the code file has not been traversed completely, it traverses the next statement. Once the code file traversal is complete, the process ends.

[0077] This application also provides a schematic diagram of the structure of a code file analysis device, such as... Figure 5 As shown, it includes:

[0078] The receiving module 502 is used to receive the code file to be identified.

[0079] The first identification module 504 is used to traverse the code file and identify the set of valid statements in the code file, wherein the set of valid statements includes statements in the code file other than code comment statements.

[0080] The second identification module 506 is used to identify the identifier segment of each statement in the set of valid statements, wherein the identifier segment is determined based on a number of predefined characters.

[0081] The determination module 508 is used to determine the target identifier segment that meets the preset function determination rules from the identifier segment, determine the target identifier segment as the target function to be called, and determine the position of the target identifier segment in the code file as the position of the target function.

[0082] It should be noted that, Figure 5 The analysis device for the code file shown is used to execute Figure 2The code file analysis method shown, therefore Figure 2 The explanations and descriptions in the code file analysis method also apply to the code file analysis device, and will not be repeated here.

[0083] It should be noted that the modules in the analysis device of the above code file can be program modules (e.g., a set of program instructions that implement a certain function) or hardware modules. For the latter, they can be represented in the following forms, but are not limited to these: each of the above modules is represented by a processor, or the functions of each of the above modules are implemented by a processor.

[0084] This application also provides a non-volatile storage medium, which includes a stored program, wherein, during program execution, the device where the non-volatile storage medium is located executes the code file analysis method of any of the above embodiments.

[0085] This application also provides an electronic device, which includes a processor for running a program, wherein the program executes the code file analysis method of any of the above embodiments during runtime.

[0086] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the code file analysis method of any of the above embodiments.

[0087] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0088] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0089] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0090] Furthermore, the functional units in the various embodiments of this application 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.

[0091] 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, the technical solution of this application, in essence, or the part that contributes to related technologies, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0092] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for analyzing code files, characterized in that, include: Receive the code file to be identified; The code file is traversed to identify a set of valid statements in the code file, wherein the set of valid statements includes statements other than code comment statements in the code file; Identify the identifier segment for each statement in the set of valid statements, wherein the identifier segment is determined based on a plurality of predefined characters; From the identifier segments, a target identifier segment that satisfies the preset function determination rules is determined, and the target identifier segment is determined as the target function to be called, and the position of the target identifier segment in the code file is determined as the position of the target function; The step of determining the target identifier segment that satisfies the preset function determination rule from the identifier segments includes: verifying the first type of identifier segments in a first manner to obtain the target identifier segment, wherein the first type of identifier segments are identifier segments that satisfy the preset code environment requirements in the preset function determination rule, and the first manner is a preset function identification method corresponding to the preset code environment requirements; and verifying the second type of identifier segments in a second manner to obtain the target identifier segment, wherein the second type of identifier segments are identifier segments other than the first type of identifier segments, and the second manner is a function identification method predefined in the preset function determination rule for the second type of identifier segments. The step of verifying the first type of identifier segment in the first method to obtain the target identifier segment includes: determining a scope as a character region in each of the first type of identifier segments that starts with a first preset keyword and ends with a second preset keyword, wherein the first preset keyword is used to define a function and the second preset keyword is used to indicate the end of the function; for each scope, removing characters that match the character names in a preset variable declaration list to obtain an initial target identifier segment, wherein each scope corresponds to a preset variable declaration list; and determining the initial target identifier segment that does not belong to the function call context as the target identifier segment. The step of verifying the second type of identifier segment in the second way to obtain the target identifier segment includes: determining the second type of identifier segment as the target identifier segment when the following conditions are met simultaneously: the second type of identifier segment does not start with a number; the second type of identifier segment does not belong to the preset global variable or preset function character declared in the code file; the second type of identifier segment does not belong to the preset variable declared in the statement corresponding to the second type of identifier segment.

2. The method according to claim 1, characterized in that, The method further includes: The objective function set is composed of all objective functions determined based on all identifier segments in the set of valid statements. The function call relationships between the target functions in the target function set are determined based on a preset script file, wherein the preset script file is used to indicate all function names contained in the code file; A function call tree is constructed based on the function call relationship and the set of target functions, wherein the function call tree is used to indicate the call path and hierarchical relationship between the target functions.

3. The method according to claim 1, characterized in that, The code file to be identified includes: a class definition file, and the method further includes: Identify the first and second fields belonging to the first preset format from the identifier segment of the class definition file, and identify the preset symbols from the class definition file; From the class definition file, target fields conforming to a second preset format are identified, wherein the second preset format includes the following fields arranged in the following order: the first field, the preset symbol, and the second field; If it is determined that the target field is a non-variable declaration and the first field is a declared variable, then determine the first function that defines the first field and determine the category of the first function; When the category of the first function is the same as the name of any defined class, the defined class with the same name is identified as the target class, and the first field is identified as an object of the target class, wherein the target field is the field that is called.

4. The method according to claim 1, characterized in that, The code file to be identified includes: a class definition file, and the method further includes: Identify the first and second fields belonging to the first preset format from the identifier segment of the class definition file, and identify the preset symbols from the class definition file; From the class definition file, target fields conforming to a second preset format are identified, wherein the second preset format includes the following fields arranged in the following order: the first field, the preset symbol, and the second field; If it is determined that the target field is a variable declaration, and it is determined that the target field is not the field being called, then the target field is stored as a variable.

5. The method according to claim 1, characterized in that, The code file to be identified includes: a class definition file, and the method further includes: Identify the first and second fields belonging to the first preset format from the identifier segment of the class definition file, and identify the preset symbols from the class definition file; From the class definition file, target fields conforming to a second preset format are identified, wherein the second preset format includes the following fields arranged in the following order: the first field, the preset symbol, and the second field; If it is determined that the target field is not a variable declaration and the first field is not a declared variable, then the first field is determined to be a class name, and the target field is a field that is called based on the class name.

6. The method according to claim 1, characterized in that, The code file to be identified includes: a class definition file, and the method further includes: Identify the first and second fields belonging to the first preset format from the identifier segment of the class definition file, and identify the preset symbols from the class definition file; From the class definition file, target fields conforming to a second preset format are identified, wherein the second preset format includes the following fields arranged in the following order: the first field, the preset symbol, and the second field; If the target field is determined to be a non-variable declaration, the first field is a declared variable and the first function defining the first field cannot be determined, or the first function defining the first field is determined and the category of the first function is different from the name of any defined class, then the first field is determined to be an undefined class or a directly input variable.

7. An analysis device for code files, characterized in that, include: The receiving module is used to receive the code file to be identified; The first identification module is used to traverse the code file and identify a set of valid statements in the code file, wherein the set of valid statements includes statements in the code file excluding code comment statements; The second identification module is used to identify the identifier segment of each statement in the set of valid statements, wherein the identifier segment is determined based on a plurality of predefined characters; A determining module is configured to determine a target identifier segment from the identifier segments that satisfies a preset function determination rule, determine the target identifier segment as the target function to be called, and determine the position of the target identifier segment in the code file as the position of the target function; the determination of the target identifier segment from the identifier segments that satisfies the preset function determination rule includes: verifying a first type of identifier segment in a first manner to obtain the target identifier segment, wherein the first type of identifier segment is an identifier segment that satisfies the preset code environment requirements in the preset function determination rule, and the first manner is a preset function identification method corresponding to the preset code environment requirements; verifying a second type of identifier segment in a second manner to obtain the target identifier segment, wherein the second type of identifier segment is an identifier segment other than the first type of identifier segment, and the second manner is a function identification method predefined in the preset function determination rule for the second type of identifier segment; The step of verifying the first type of identifier segment in the first method to obtain the target identifier segment includes: determining a scope as a character region in each of the first type of identifier segments that starts with a first preset keyword and ends with a second preset keyword, wherein the first preset keyword is used to define a function and the second preset keyword is used to indicate the end of the function; for each scope, removing characters that match the character names in a preset variable declaration list to obtain an initial target identifier segment, wherein each scope corresponds to a preset variable declaration list; and determining the initial target identifier segment that does not belong to the function call context as the target identifier segment. The step of verifying the second type of identifier segment in the second way to obtain the target identifier segment includes: determining the second type of identifier segment as the target identifier segment when the following conditions are met simultaneously: the second type of identifier segment does not start with a number; the second type of identifier segment does not belong to the preset global variable or preset function character declared in the code file; the second type of identifier segment does not belong to the preset variable declared in the statement corresponding to the second type of identifier segment.

8. A non-volatile storage medium, characterized in that, The non-volatile storage medium stores a program, wherein when the program is executed, it controls the device where the non-volatile storage medium is located to execute the code file analysis method according to any one of claims 1 to 6.

9. An electronic device, characterized in that, include: A memory and a processor, the processor being configured to run a program stored in the memory, wherein the program, when running, executes the method for analyzing a code file as described in any one of claims 1 to 6.

10. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the code file analysis method according to any one of claims 1 to 6.

Images