SPEL-based user-defined identifier dynamic identification and completion method and system

Abstract

The invention discloses a method and a system for dynamically identifying user-defined identifiers and automatically complementing codes on the basis of SPEL (Single Performance Execution Language). The method comprises the steps that editing operation of a user on SPEL codes is monitored in real time, and when a cursor leaves a current line, code snippets before and after editing are obtained and compared; based on a preset SPEL grammar regular expression, the changed code is analyzed to recognize a newly-added user-defined identifier, and the newly-added user-defined identifier is dynamically added into a completion library; meanwhile, the code before change is analyzed to identify the modified or deleted identifier, and the failure item is removed from the completion library; finally, during subsequent input by the user, a dynamic, context-related automatic completion prompt is provided based on the updated completion library. The system comprises a code change monitoring module (1), a difference comparison module (2), a grammar analysis module (3), a code completion library updating module (4) and a code completion prompting module (5). The invention relates to the technical field of industrial robot programming.

Description

Technical Field

[0001] This invention relates to industrial robot programming technology and internet information service technology, specifically to a method and system for dynamic recognition and completion of user-defined identifiers based on SPEL (Structured Process Expression Language). This invention is applicable to cloud-based integrated development environments (Cloud IDEs) and internet code search services, aiming to improve the programming efficiency of robot engineers through networked and intelligent data processing. Background Technology

[0002] In the development of industrial robot applications, programming is the core bridge connecting engineers' intentions with machine actions. Currently, industrial robot programming solutions on the market are mainly divided into two schools of thought: one uses mature, general-purpose programming languages, such as Lua used by Delta Robotics and Zowell Robotics; the other uses proprietary programming languages ​​developed by robot manufacturers, such as Epson Robotics' SPEL+ language, Hikvision Robotics' unnamed self-developed language, and ABB Robotics' RAPID language.

[0003] The advantage of using a general-purpose programming language lies in its seamless integration with industry-leading integrated development environments (IDEs) such as Visual Studio Code and IntelliJ IDEA. These IDEs have powerful built-in IntelliSense features that provide accurate code auto-completion for user-defined variables, functions, and their parameters, greatly improving development efficiency and code quality. However, for vendors using self-developed proprietary languages, the intelligent features of their accompanying IDEs are often very weak due to the lack of mature Language Server Protocol (LSP) support and a large developer community.

[0004] According to incomplete market research, among mainstream industrial robot products on the market, only Inovance Robotics has implemented a relatively complete user-defined identifier completion function in its self-developed language IDE. Epson Robotics, a major user of the SPEL+ language, has an official IDE that can only complete user-defined function names, offering no suggestions whatsoever for more basic and frequently used user-defined variable names or function parameter names. The situation is even more severe for Hikvision Robotics and ABB Robotics; their IDEs cannot even complete user-defined function names.

[0005] This technological deficiency has caused significant challenges for frontline engineers. When developing large, complex automation projects, engineers need to remember numerous variable names, function names, and parameter names defined by themselves or team members. Forgetting these requires repeatedly searching through multiple code files, severely slowing down development and significantly reducing code readability and maintainability. Therefore, there is an urgent need for a technical solution that can deeply understand the SPEL+ language syntax and dynamically identify and manage user-defined identifiers in real time to fill this market gap. Summary of the Invention

[0006] The purpose of this invention is to overcome the aforementioned deficiencies in the existing technology and provide a method and system for dynamic recognition and completion of user-defined identifiers based on SPEL. The core objective of this invention is to achieve comprehensive, accurate, and real-time code auto-completion for three types of key identifiers—user-defined variables, user-defined functions, and function parameters—within a robot IDE, thereby improving the development efficiency of robot engineers and enhancing the interactive experience of the SPEL+ language.

[0007] The technical solution adopted in this invention is a method for dynamic recognition and automatic code completion of user-defined identifiers based on the SPEL language, which includes the following steps: S1. Real-time monitoring of user input or modification operations on SPEL language code in the integrated development environment; S2. When the user finishes editing the current line of code and leaves the line, obtain the code snippets before and after the editing of the line of code, define the code snippet before editing as the first code snippet, and define the code snippet after editing as the second code snippet; S3. Compare the first code segment with the second code segment to determine the changed code content; S4. Based on the preset SPEL language syntax regular expression, perform syntax type judgment and parsing on the second code segment to identify the user-defined identifier declaration contained therein; S5. When a user-defined identifier declaration is identified, the corresponding identifier name is extracted from the second code snippet and dynamically added to the code completion candidate library. S6. When it is detected that a user-defined identifier declaration has been modified or deleted, remove the corresponding invalid identifier name from the code completion candidate library; S7. The contents of the code completion candidate library are called in real time when the user subsequently inputs SPEL language code, so as to realize dynamic and context-dependent automatic completion suggestions for user-defined identifiers.

[0008] Furthermore, step S1 also includes the following steps: S11. Before the user starts editing a line of code, the current code content of that line is pre-cached as the first code fragment; S12. When the user moves the text cursor away from the current editing line, cache the final code content of that line as the second code fragment.

[0009] Furthermore, step S3 specifically includes: S31. Compare the first code segment and the second code segment character by character to determine whether there is a difference between them. If there is a difference, trigger step S4.

[0010] Furthermore, step S4 is as follows: S41. Simultaneously use SPEL user-defined variable declaration syntax regular expressions and SPEL user-defined function declaration syntax regular expressions to match the second code snippet; S42. When only the regular expression for the SPEL user-defined variable declaration syntax is successfully matched, it is determined to be a variable declaration; S43. When the regular expression for the SPEL user-defined function declaration syntax is successfully matched, it is determined to be a function declaration.

[0011] Furthermore, when a variable declaration is identified, the corresponding identifier name is extracted from the second code snippet and dynamically added to the code completion candidate library, specifically as follows: S421. Use the SPEL user-defined variable declaration syntax regular expression to match the iterator and obtain the matched identifiers one by one. S422. Determine whether the first matching item of the iterator belongs to the preset SPEL language data type keyword set; S423. When it belongs to the set of data type keywords, the legal identifiers subsequently matched by the iterator are added to the code completion candidate library as user-defined variable names in turn.

[0012] Furthermore, when the code is determined to be a function declaration, the corresponding identifier name is extracted from the second code snippet and dynamically added to the code completion candidate library, specifically as follows: S431. Extract function names using SPEL user-defined function declaration syntax regular expressions and add the function names to the code completion candidate library; S432. Obtain the parameter list content through the SPEL user-defined function declaration syntax regular expression; S433. Use independent parameter matching regular expressions to split the contents of the parameter list one by one, extract the identifier name of each parameter in turn, and add each parameter name to the code completion candidate library.

[0013] Furthermore, step S6 is as follows: S61. For the modified or deleted variable declaration line, use the SPEL user-defined variable declaration syntax regular expression to match the first code segment, extract the original variable name, and remove the corresponding variable name from the code completion candidate library. S62. For the modified or deleted function declaration line, use the SPEL user-defined function declaration syntax regular expression to match the first code segment, extract the original function name and all parameter names, and remove the corresponding function name and all related parameter names from the code completion candidate library.

[0014] Furthermore, the code completion candidate library includes at least three independent subsets: a set of user-defined variables, a set of user-defined functions, and a set of user-defined function parameters.

[0015] Furthermore, step S7 is as follows: S71. During the user's code input process, when the input characters reach the preset threshold or the completion shortcut key is triggered, retrieve all user-defined variable names, function names, and valid formal parameter names within the current function scope that match the current input prefix from the code completion candidate library; S72. The search results are sorted according to preset priority rules and then presented to the user.

[0016] A system for implementing the method described above, the system comprising: The code change monitoring module is used to monitor the user's input or modification operations on SPEL language code in the integrated development environment in real time, and when the user finishes editing the current line of code and the cursor leaves the line, it obtains the first code snippet before the line of code was edited and the second code snippet after the line of code was edited. The difference comparison module is used to compare the first code segment and the second code segment to determine whether there are differences in code content; The syntax parsing module is used to determine and parse the syntax type of the first code segment and the second code segment respectively according to the preset SPEL language syntax regular expression when there are differences; The code completion library update module performs the following operations based on the parsing results from the syntax parsing module: When the second code snippet is identified as containing a user-defined identifier declaration, the corresponding identifier name is extracted from the second code snippet and dynamically added to the code completion candidate library; When the first code snippet is identified as containing a user-defined identifier declaration that has been modified or deleted, the corresponding invalid identifier name is removed from the code completion candidate library; The code completion suggestion module is used to call the contents of the code completion candidate library in real time when the user subsequently enters SPEL language code, so as to provide the user with dynamic and context-sensitive auto-completion suggestions for user-defined identifiers.

[0017] The beneficial effects of this invention are as follows: 1. Filling a market gap: For industrial robots using self-developed proprietary programming languages ​​such as SPEL+ (e.g., Epson, Hikvision, ABB), it is the first to achieve comprehensive and dynamic code auto-completion for three types of key identifiers: user-defined variables, functions, and function parameters, solving a major functional deficiency in this aspect of existing official IDEs.

[0018] 2. Significantly improves development efficiency: Engineers no longer need to memorize or repeatedly search for complex custom identifier names across multiple files. Real-time, accurate completion suggestions greatly reduce manual input and speed up coding, especially when developing large, complex projects.

[0019] 3. Effectively reduces error rate: The auto-completion function can effectively avoid spelling and syntax errors caused by manual input (for example, by automatically generating parameter placeholders for function calls), thereby improving the first-time accuracy and overall quality of the code.

[0020] 4. Enhanced code readability and maintainability: Unified and intelligent code completion makes the code style more consistent and the logic clearer, greatly facilitating code reading, understanding and later maintenance.

[0021] 5. Optimize user experience: By providing context-sensitive and priority-based completion suggestions, as well as supporting personalized adjustments, the interactive experience of the SPEL+ programming language has been greatly enhanced, allowing engineers to focus more on business logic rather than tedious syntax details. Attached Figure Description

[0022] Figure 1 This is a simplified structural block diagram of the system of the present invention; Figure 2 This is a flowchart of the method of the present invention. Detailed Implementation

[0023] like Figure 1 As shown, the system of the present invention includes: Code change monitoring module 1 is used to monitor the user's input or modification operations on SPEL language code in the integrated development environment in real time, and when the user finishes editing the current line of code and the cursor leaves the line, it obtains the first code snippet before the line of code is edited and the second code snippet after the line of code is edited. The difference comparison module 2 is used to compare the first code segment and the second code segment to determine whether there are differences in code content; Syntax parsing module 3 is used to determine and parse the syntax type of the first code segment and the second code segment respectively according to the preset SPEL language syntax regular expression when there are differences; The code completion library update module 4 is used to perform the following operations based on the parsing results of the syntax parsing module: When the second code snippet is identified as containing a user-defined identifier declaration, the corresponding identifier name is extracted from the second code snippet and dynamically added to the code completion candidate library; When the first code snippet is identified as containing a user-defined identifier declaration that has been modified or deleted, the corresponding invalid identifier name is removed from the code completion candidate library; The code completion suggestion module 5 is used to call the contents of the code completion candidate library in real time when the user subsequently enters SPEL language code, so as to provide the user with dynamic and context-dependent automatic completion suggestions for user-defined identifiers.

[0024] This invention provides a method for dynamic recognition and completion of user-defined identifiers based on SPEL, implemented using the aforementioned system. This method is applied in the field of industrial robot programming, and is particularly suitable for integrated development environments using the SPEL+ programming language. It aims to achieve automatic recognition and code completion of user-defined variables, functions, and formal parameters, thereby improving programming efficiency and user experience.

[0025] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings. Figure 2 This is a schematic diagram of the overall process of the method of the present invention. The core of the method lies in capturing changes to code snippets by monitoring user operations in the code editing area, especially the movement of the text cursor, and dynamically updating a code completion library by using a series of specially designed regular expressions to perform syntactic analysis on the code before and after the changes. This code completion library is used to provide completion suggestions, including user-defined identifiers, when the user subsequently enters code.

[0026] Step S1: Respond to the user's editing operation on the target line of code in the code editing area and obtain the first code snippet before editing.

[0027] Specifically, the integrated development environment (IDE) continuously monitors activity in the code editing area. When it detects that a user has positioned the text cursor on a line of code and is preparing to input or modify it, this method immediately triggers a recording action. This recording action occurs before the user actually modifies any characters, aiming to capture the original state of that line of code before the current editing operation. Here, the target line of code refers to the line where the text cursor is currently located, and the first code snippet is the complete text content of that line before editing. For example, if the user moves the cursor to a blank line to define a new variable, the first code snippet recorded would be an empty string. Or, for instance, if the user moves the cursor to an existing line of code, "Integer var_1," intending to modify it into a function definition, the first code snippet recorded would be "Integer var_1". Obtaining the first code snippet is fundamental for subsequent difference comparisons and syntax analysis, ensuring the system knows exactly what the user has modified.

[0028] Step S2: Respond to the user's edit completion operation and obtain the edited second code snippet.

[0029] The completion of an editing operation is typically indicated by the text cursor leaving the current editing line. When the user moves the text cursor away from the target code line described in step S1 by pressing the Enter key, clicking on another line with the mouse, or using a keyboard shortcut, the system determines that the user's editing operation on that line is complete. At this point, the method will trigger the recording action again to capture the latest state of the line of code after editing, i.e., the second code snippet. Continuing the example above, if the user enters "Integer var_1" on a blank line and presses the Enter key, then the second code snippet is "Integervar_1". If the user changes the original "Integer var_1" to "Function fun_2(var_2 As Integer)" and moves the cursor away, then the second code snippet is "Function fun_2(var_2 As Integer)". Steps S1 and S2 together complete the capture of a code change event, recording the two states before and after the change.

[0030] Step S3: Determine whether there is a difference between the first code segment and the second code segment.

[0031] After obtaining the first and second code snippets, it's necessary to determine whether the user has actually made substantial modifications to the code content. This step is achieved through a simple string comparison. The first and second code snippets are compared character by character. If they are identical, it means that although the user performed operations such as cursor movement, the code text content has not been changed. In this case, there's no need to trigger subsequent syntax analysis and library update processes; the method can end directly or wait for the next editing event. If there are any differences, even just a single space or the addition or removal of a single character, it is considered a difference, and the subsequent step S4 is executed. This judgment mechanism avoids unnecessary processing overhead; the relatively resource-intensive regular expression analysis and library update operations are only initiated when the code content has actually changed.

[0032] Step S4: If there is a difference, perform a first syntax analysis on the first code segment based on the preset user-defined variable syntax rules to obtain a first analysis result.

[0033] Since the first code snippet represents the old code before it was modified or deleted, the purpose of this step is to analyze the syntactic structure of this old code, specifically to identify whether it contains user-defined identifiers that need to be removed from the code completion library. The preset syntax rules for user-defined variables are formally defined using regular expressions to match typical syntax patterns for defining variables in the SPEL+ language. In one embodiment, the regular expression is designed to recognize identifiers that begin with a letter or underscore, followed by zero or more letters, numbers, or underscores, and optionally end with a dollar sign $ to indicate a string type. The expression will also match all such identifier patterns appearing in the line.

[0034] The first code snippet undergoes initial syntax analysis, specifically using a regular expression to match it. For example, for the code snippet "Integer var_1", the regular expression will successfully match and extract two matches: "Integer" and "var_1". The initial analysis result contains information about these matches and the success or failure of the match. If the code snippet is an empty string, the regular expression will not match anything, and the initial analysis result will be a match failure. If the code snippet is "String var_2$, var_3$", the regular expression will match three items: "String", "var_2$", and "var_3$". It should be noted that this step only performs preliminary syntax pattern matching and does not yet distinguish between keywords and user-defined variable names.

[0035] Step S5: Based on the first analysis result, perform a first update operation on the code completion library. The first update operation is used to remove user-defined identifiers contained in the first code snippet.

[0036] This step cleans up the code completion library based on the analysis results of step S4. The core logic is: if a user-defined variable was defined in the first code snippet, and that line of code has now been modified or deleted, then that variable name should be removed from the completion library to prevent it from providing incorrect or outdated completion suggestions in subsequent programming.

[0037] Specifically, the first step is to identify from the initial analysis results which matches are genuine user-defined variable names, rather than data type keywords from the SPEL+ language. In SPEL+ syntax, statements defining variables always begin with a data type keyword, such as Integer, String, Double, etc. Therefore, this can be determined by checking if the first item in the regular expression match exists in a predefined list of data type keywords. This list is loaded from the SPEL+ syntax file during integrated development environment (IDE) initialization.

[0038] If the first item in the match result is a data type keyword, then it can be determined that the line of code was originally a variable definition statement. Next, all subsequent items matched by the regular expression need to be traversed. In one implementation, this is done using a tool called an iterator to access each match. Starting with the second match, each match represents a variable name defined in that line. For each such variable name, a dedicated interface function provided by the code completion library is called, such as a function called "removeUserVar," to remove the variable name from the library.

[0039] For example, in the first code snippet "Integer var_1", the first matched item "Integer" is a data type keyword. Therefore, the subsequent "var_1" is recognized as a user-defined variable name, and "removeUserVar("var_1")" is called to remove it from the completion library. For "String var_2$, var_3$", the first item "String" is a keyword, so both "var_2$" and "var_3$" will be recognized and removed from the library sequentially. If the first analysis result fails to match, or the first matched item is not a data type keyword, no removal operation is performed in this step.

[0040] Step S6: Based on the preset user-defined variable syntax rules and user-defined function syntax rules, perform a second syntax analysis on the second code segment to obtain a second analysis result.

[0041] After cleaning up any autocomplete entries that might have been generated by the old code, the next step is to analyze the new code, namely the second code snippet, to identify the newly added user-defined identifiers. This step uses two sets of syntax rules for analysis: one is the user-defined variable syntax rule already used in step S4, and the other is the newly added user-defined function syntax rule. The user-defined function syntax rule is more complex because it needs to match various forms of function definitions, including function names, optional parameter lists, etc. This rule is also defined by regular expressions, and its design covers various situations that may occur when defining functions in the SPEL+ language, such as whether there are no parameters, the declaration method of parameters when there are parameters (whether it contains the ByRef keyword, whether it is an array, data type, etc.), and the declaration of the function return type, etc.

[0042] The second parsing process involves attempting to match the second code snippet using regular expressions that specify variable and function syntax rules, respectively. The analysis results record which rule matched successfully and the specific content matched. For example, for the code snippet "Integer var_1", only variable syntax rules will match successfully. For the code snippet "Function fun_2(var_2 As Integer)", only function syntax rules will match successfully. The analysis results indicate whether the current code snippet's syntax type is a variable definition or a function definition, which is crucial in determining which update path to execute subsequently.

[0043] Step S7: Based on the second analysis result, perform a second update operation on the code completion library; wherein, if the second analysis result indicates that the second code segment conforms to the variable definition syntax, the second update operation is used to add the variable name in the second code segment to the code completion library; if the second analysis result indicates that the second code segment conforms to the function definition syntax, the second update operation is used to add the function name in the second code segment to the code completion library.

[0044] This step, based on the analysis conclusions of step S6, adds new completion items to the code completion library. It consists of two main processing paths.

[0045] The first path is for variable definitions. If the second analysis result indicates a successful match of the variable syntax rule, further verification is required: using the same method as in step S5, check if the first item in the matching result is a data type keyword. If so, it confirms that this is a valid variable definition statement. Subsequently, iterate through all identifiers starting from the second item in the matching result, each representing a user-defined variable name. For each variable name, call the add interface function of the code completion library, such as "appendUserVar", to add it to the library. For example, for "Integer var_1", add "var_1" to the library; for "String var_2$, var_3$", add "var_2$" and "var_3$" to the library in sequence.

[0046] The second path targets the function definition. If the second analysis indicates a successful match of the function syntax rules, the function name needs to be extracted from the second code snippet. Since the content matched by the regular expression for the function syntax rules may contain redundant characters such as the keyword "Function," spaces, and left parentheses, further processing is required. In one embodiment, a more precise regular expression specifically designed for extracting function names (i.e., a "user-defined function name syntax format") is used to match the second code snippet again to directly capture the clean function name. For example, "fun_2" is matched from "Function fun_2(var_2 As Integer)". After obtaining the function name, another add interface function of the code completion library, such as "appendUserFunc", is called to add the function name to the library.

[0047] Through steps S4 to S7, the method completes a full cycle of dynamic updating of the completion library by "cleaning up old items first and then adding new items", ensuring the accuracy and timeliness of the completion suggestions.

[0048] Step S8: In response to the user's code input operation in the code editing area, provide code completion suggestions based on the updated code completion library.

[0049] After the code completion library is dynamically updated based on the user's editing behavior, the integrated development environment's (IDE) code completion function can use this latest library to provide suggestions when the user types in the code editing area again. Specifically, the system monitors the user's input characters in real time. When the user enters a specific trigger character (such as a letter or underscore) or actively invokes a completion shortcut, the completion engine is activated. The completion engine obtains the context information of the current cursor position, such as the part of the word before the cursor, and then compares it with all entries in the code completion library. The code completion library not only includes SPEL+ language-specific keywords and standard library functions, but now also user-defined variable names and function names dynamically added through the aforementioned steps.

[0050] The code completion engine finds all entries that match the current input prefix and displays them in a list in the user interface, usually a drop-down list. Users can select the desired item from the list to quickly complete code input. For example, if a user previously defined a variable "var_1", when they type "va" in subsequent code, "var_1" will appear in the completion list for selection. Similarly, if a user defined a function "fun_2", "fun_2" will also appear in the list when they type "fu". This eliminates the need for users to remember or manually type lengthy and potentially complex custom identifiers, greatly improving programming efficiency and accuracy and reducing program errors caused by spelling mistakes.

[0051] In one embodiment, the first syntax analysis of the first code segment based on the preset user-defined variable syntax rules in step S4 specifically includes step S41.

[0052] Step S41: Use a first regular expression to match the first code fragment; the first regular expression is used to match an identifier pattern that begins with a letter or underscore, is followed by zero or more alphanumeric underscores, and optionally ends with a dollar sign.

[0053] This section provides more specific restrictions on the first regular expression. Its core pattern can be described as follows: it must begin with a single English letter (uppercase or lowercase) or an underscore. Following the initial character, zero or more characters can follow, which can be English letters, numbers, or underscores. Additionally, a dollar sign "$" can optionally appear at the end of the entire identifier. In SPEL+, string variable names must end with a dollar sign, so this design is intended to be compatible with both regular and string variables. This regular expression can match all consecutive character sequences in a line of code that conform to this pattern. For example, for the code "ByRef myVar_123 As Integer", it can match "ByRef", "myVar_123", "As", and "Integer". Although "ByRef" and "As" are not variable names, they also conform to the pattern. These need to be excluded in subsequent steps, specifically by determining whether the first match is a data type keyword, to effectively distinguish and filter out these non-variable name matches, thus ensuring the accuracy of variable name identification. This design ensures comprehensive matching, avoiding the omission of any possible variable names.

[0054] In one embodiment, step S5, which involves performing a first update operation on the code completion library based on the first analysis result, specifically includes steps S51 to S53.

[0055] Step S51: If the first regular expression matches successfully, then obtain the multiple matched items.

[0056] When the first regular expression in step S41 successfully matches content, the result is not a single value, but a collection containing all substrings in that line of code that match the pattern. These substrings are organized in an ordered manner and can be accessed one by one using an iterator. For example, matching "Integer var_1, var_2" will yield three matches: "Integer", "var_1", and "var_2". Obtaining these matches is a prerequisite for subsequent filtering and operations.

[0057] Step S52: Determine whether the first matching item exists in the preset set of data type keywords.

[0058] The data type keyword set is a group of reserved words in the SPEL+ language used to declare variable types, such as "Integer", "String", "Double", "Real", and "Boolean". This set is loaded into a list container in memory during system initialization. The purpose of this step is to determine whether the line of code is indeed a variable definition statement. In SPEL+ syntax, the first valid word of a variable definition statement must be a data type keyword. Therefore, a judgment can be made by checking whether the first item matched by the first regular expression is in this pre-defined set. If it exists, it indicates that the line of code is very likely a variable definition and can continue processing; if it does not exist, it means that although the line of code matches the pattern, it may not be a variable definition (for example, it may be a regular assignment statement or expression), and therefore no item should be removed from the completion library.

[0059] Step S53: If the first matching item exists in the data type keyword set, then traverse the remaining matching items except for the first matching item, and remove each traversed matching item as a user-defined variable name from the code completion library.

[0060] When the judgment in step S52 is true, it can be safely assumed that starting from the second match, each match is a user-defined variable name defined in that line. A loop is used to sequentially access each such match. For each accessed variable name, the removal function provided by the code completion library is called. This removal function searches for the corresponding entry in the completion library based on the variable name and deletes it. For example, for a sequence of matches, "removeUserVar("var_1")" and "removeUserVar("var_2")" will be called sequentially. This precisely cleans up variable name completion suggestions that became invalid due to the modification or deletion of that line of code.

[0061] In one embodiment, the second syntax analysis of the second code segment based on preset user-defined function syntax rules in step S6 specifically includes step S61.

[0062] Step S61: The second code snippet is matched using a second regular expression. This second regular expression matches syntax patterns containing function definition keywords, function names, optional parameter lists, and optional return type declarations. The second regular expression is a compound regular expression, constructed from three interrelated sub-regular expressions: a "user-defined function name syntax format" for matching function names, a "user-defined function parameter list syntax format" for matching the entire parameter list, and a "user-defined function parameter syntax format" for extracting individual parameter names from parameter declarations. This modular design allows complex function definition statements to be parsed systematically and accurately.

[0063] The second regular expression for user-defined function syntax rules is much more complex than the first because it needs to describe a structured syntactic unit. Its design goal is to match lines that begin with the keyword "Function" and capture the function name defined after it, as well as the parameter list enclosed in parentheses that may follow the function name. The parameter list itself may contain multiple parameters, each with its own name, an optional "ByRef" keyword, optional pairs of parentheses representing arrays, and a data type indicated by the "As" keyword. Furthermore, the function definition may also include a return type declaration indicated by the "As" keyword at the end.

[0064] The second regular expression is constructed by combining multiple sub-patterns and allowing them to appear optionally. For example, it ensures that the keyword "Function" must appear, followed by a function name (conforming to variable naming rules), which can be followed by a left parenthesis or not (for parameterless functions). The parameter list as a whole is designed as an optional pattern, internally describing the syntax for a single parameter and the syntax for multiple parameters separated by commas. The entire expression also considers any number of whitespace characters that may exist in the code to accommodate different user coding styles. When the second code snippet conforms to the SPEL+ function definition syntax, the second regular expression matches successfully, thus marking the code snippet as a function definition type in the second analysis result.

[0065] In one embodiment, in step S7, if the second analysis result indicates that the second code segment conforms to the function definition syntax, the second update operation is used to add the function name in the second code segment to the code completion library, specifically including steps S71 to S72.

[0066] Step S71: Use a third regular expression to extract the function name from the second code segment; the third regular expression is used to match the function name part from the function definition statement.

[0067] While a second regular expression can determine if a line of code is a function definition, its matched content may contain non-function name parts such as "Function", spaces, and left parentheses. To accurately extract the pure function name, a more focused third regular expression is needed. This third regular expression is typically designed to match the string of characters that conform to the identifier rules after the keyword "Function" and before the left parenthesis or the end of the line. It effectively filters out interfering characters before and after, directly capturing the function name itself. For example, for the code "Function CalculateSum(a As Integer, bAs Integer) As Integer", the third regular expression should be able to match and extract "CalculateSum".

[0068] Step S72: Add the extracted function names to the code completion library.

[0069] After obtaining the function name string in step S71, the code completion library's add function interface is directly called, for example, "appendUserFunc," to store this string as a new user-defined function name in the completion library. Afterward, when the user enters the first few letters of this function name, the function name will appear in the completion suggestion list.

[0070] In one embodiment, in step S7, if the second analysis result indicates that the second code fragment conforms to the function definition syntax, the second update operation further includes step S73.

[0071] Step S73: Extract the parameter list from the second code snippet and add the parameter names in the parameter list to the code completion library.

[0072] Besides the function name, the parameter names are also important user-defined identifiers and are frequently used within the function body. Therefore, a more robust implementation would also include parameter names in the completion library. This step first requires extracting the complete parameter list string from the second code snippet. This can be obtained by matching a specific capture group in the result of the second regular expression, or by using another regular expression specifically for matching parameter lists (i.e., the "user-defined function parameter list syntax format").

[0073] After obtaining the parameter list string (e.g., "(a As Integer, b As Integer)"), it's necessary to further parse out each individual parameter name. This can be achieved by iterating through the parameter list string and using a regular expression (i.e., a "user-defined function parameter syntax") to match individual parameters. This regular expression will match the core part of the parameter declaration: the parameter name. For example, "(a As Integer, b As Integer)" will match "a" and "b". For more complex declarations like "(ByRef arr() As Double)", the regular expression should match "arr".

[0074] Finally, each parsed parameter name is added to the code completion library via the corresponding interface function (e.g., "appendUserVar"). This way, when a user writes code within the function body, they can get completion suggestions even by typing the first few letters of the parameter name, further improving coding convenience.

[0075] In one embodiment, the step S73 of extracting the parameter list from the second code segment specifically includes step S731.

[0076] Step S731: Use the fourth regular expression to match the second code segment to obtain the parameter list string; the fourth regular expression is used to match the parameter list part enclosed in parentheses in the function definition.

[0077] The fourth regular expression is specifically designed for extracting parameter lists. Its core pattern is to match a left parenthesis, then match everything within the parentheses until the corresponding right parenthesis. The content within the parentheses must conform to the syntax rules of parameter declarations, meaning it may contain multiple comma-separated parameter declaration units. This regular expression can precisely extract parameter list substrings from complex function definition lines. For example, from "Function ProcessData(ByRef input()As Double, threshold As Real) As Boolean", the fourth regular expression can match and capture the string "ByRef input() As Double, threshold As Real". This string becomes the input for subsequent parameter name parsing.

[0078] In one embodiment, adding the parameter names in the parameter list to the code completion library in step S73 specifically includes steps S732 to S733.

[0079] Step S732: Use the fifth regular expression to traverse the parameter list string and sequentially match the core parts of each parameter declaration. Then, post-process each matched core part: remove the parameter passing method keywords (such as "ByRef", "ByVal"), the data type declaration keyword "As", and the parentheses "()" representing arrays, thereby obtaining the clean parameter names.

[0080] Specifically, after obtaining the parameter list string, it needs to be broken down into individual parameter names. The fifth regular expression is designed to match the core pattern of individual parameter declarations. It ignores the "ByRef" keyword, the parentheses "()" indicating arrays, and the "As data type" part in the parameter declaration, directly locating and capturing the parameter name. This regular expression is typically configured as a global matching pattern and used in conjunction with an iterator. Using an iterator, all substrings in the parameter list string that match this pattern can be accessed sequentially. For example, for the parameter list string "ByRef input() As Double,threshold As Real", the fifth regular expression will capture "input" on the first match and "threshold" on the second match.

[0081] Step S733: Add the matched parameter name to the code completion library each time.

[0082] In the traversal loop of step S732, each time a parameter name is matched using the fifth regular expression, the add interface of the code completion library (e.g., "appendUserVar") is immediately called to store the parameter name in the library. By parsing and adding parameters simultaneously, the storage of all parameter names in the library is completed efficiently.

[0083] The above embodiments describe in detail the core process and various implementation details of the method of the present invention. By monitoring code changes, using multiple sets of regular expressions for precise syntax analysis, and dynamically maintaining a code completion library, this method achieves intelligent recognition and completion of user-defined variables, functions, and formal parameters in the SPEL+ programming language. This solves the pain point of existing self-developed language integrated development environments lacking such functionality, significantly improving the programming efficiency and code readability of robot engineers.

[0084] Step S9: In response to the user's code input operation in the code editing area, provide code completion suggestions based on the updated code completion library.

[0085] After the code completion library is dynamically updated, the system monitors the characters entered by the user in real time when the user inputs characters in the code editing area. When the user's input triggers the completion condition, the system retrieves all entries from the code completion library that match the current input prefix. It should be noted that the code completion suggestions in this embodiment follow the following rules: 1. Full Display: The system will provide complete suggestions for all matching data. For example, when a user enters the character "a", the code completion library will list all user-defined variables, functions, and system keywords that begin with "a", without truncating the list or hiding pages based on its length.

[0086] 2. Fixed sorting: Items in the completion list are strictly arranged in alphabetical order (AZ, case sensitive) and numerical order (0-9). The sorting logic is fixed and is not affected by the frequency of identifier usage, the distance between the definition position and the cursor, or the user's historical selection behavior.

[0087] 3. Categorization: The data in the code completion library is strictly divided into three categories at the underlying level: user-defined functions, user-defined variables (including formal parameters), and system keywords. These are distinguished and displayed in the completion suggestion list using specific icons or markers (e.g., functions are marked "fx", variables are marked "[...]", and keywords are marked "[X]") to facilitate quick user identification, but the overall sorting of the list still follows the aforementioned alphanumeric order.

[0088] In a preferred embodiment, the code completion candidate library is not limited to local storage but can also be deployed on a cloud server. In this embodiment, the integrated development environment (IDE) acts as a client, connecting to the cloud-based code analysis platform via a network. When a user enters code, the client transmits the input prefix to the cloud server via the internet. The cloud server, based on big data analytics, retrieves matching identifiers from massive open-source robot code repositories and user-shared libraries, and, combined with the ranking algorithm of internet search services, returns the most context-appropriate completion suggestions to the client. This architecture enables cloud-based intelligent code awareness services, allowing completion data to be updated in real time, without being limited by local storage.

[0089] Furthermore, the method of this invention also includes a big data analysis step of user programming behavior. With user authorization, the system collects anonymous code snippets and completion selection behaviors, forming big data on programming behavior. By mining this data, the system can analyze information such as the most commonly used variable naming habits and function call frequencies in the current industry. The code completion suggestion module uses these analysis results to optimize the ranking of retrieved candidate identifiers based on internet search services (e.g., a PageRank algorithm similar to search engines), prioritizing the display of high-frequency and highly relevant identifiers to the user, thereby providing a code completion service that better conforms to industry standards. This is a typical example of a big data-driven internet information service.

[0090] Furthermore, this invention supports network-based code navigation and collaborative services. When multiple engineers collaborate on the same project on an internet platform, the system's code completion library can be synchronized in real time over the network. For example, if engineer A defines a new function, the function name will immediately be synchronized to engineer B's IDE via the network, allowing engineer B to instantly see and complete the function defined by engineer A while writing code. This mechanism greatly improves the efficiency of networked collaborative development and builds an efficient website navigation service-style code interaction experience.

[0091] Step S10: Based on the user-selected completion options, automatically complete the code input and update the content of the current line of code.

[0092] When a user selects an item from the completion suggestion list, the system automatically inserts that item at the current cursor position, replacing the part of the character the user has already entered, and updating the content of the current code line. For example, if the user types "va" and the system suggests "var_1," and the user selects "var_1" using the keyboard arrow keys or mouse, the system will replace "va" before the cursor with the complete "var_1" and move the cursor after that variable name so the user can continue entering other code. It's worth noting that this process also triggers a new code change event, recording the state of the current line before and after the change, ensuring that subsequent completion library updates accurately reflect the latest code state. This autocomplete mechanism eliminates the need for users to manually type complete identifier names, reducing spelling errors caused by manual input.

[0093] Step S11: In response to the user's ignore operation on the code completion suggestions, record the user's input custom identifier and dynamically update the code completion library.

[0094] In some cases, users may ignore the system's auto-completion suggestions and instead manually enter a completely new custom identifier. For example, a user might type "newVar" and press Enter or Space without selecting any entry from the auto-completion list. The system will detect this omission and record the complete string manually entered by the user. Once the cursor leaves the current line, the system triggers a code change capture mechanism similar to step S2, comparing the newly entered code snippet with the original code snippet. If it confirms that this is a new custom identifier definition, the system will add "newVar" to the code completion library according to the syntax analysis and update process in steps S6 and S7. In this way, even if the user does not use the auto-completion function, the system can still dynamically learn and record new identifiers, ensuring the integrity of the completion library.

[0095] In one embodiment, the step S9 of providing code completion hints based on the updated code completion library specifically includes steps S91 to S92.

[0096] Step S91: Obtain the prefix character currently input by the user and the context information of the code line where the cursor is currently located.

[0097] When a user enters characters in the code editing area or triggers the autocomplete function, the system first captures the prefix characters of the user's current input, that is, a continuous string of characters before the cursor, usually a combination of letters or underscores. For example, when the user enters "fu", the system will record "fu" as a prefix character. Simultaneously, the system analyzes the context information of the code line where the cursor is located, including the code structure preceding that line and the syntax type of the current code block. For example, if the cursor is located within a function call statement, the system will mark the current context as a function call scenario. This information will be used for subsequent autocomplete selection.

[0098] Step S92: Based on the prefix character, select a set of matching completion items from the code completion library.

[0099] Based on the prefix character obtained in step S91, the system iterates through all entries in the code completion library, identifying identifiers that begin with that prefix character to form a set of matching completion items. For example, if the prefix character is "fu", entries such as "fun_1", "fun_2", and "function_3" will be filtered out, while "var_1" will not be included. This filtering process ensures that the completion suggestion list only contains content relevant to the user's current input, reducing interference from irrelevant entries.

[0100] In one embodiment, the automatic completion of code input based on user-selected completion items in step S10 specifically includes steps S101 to S102.

[0101] Step S101: In response to the user's selection of a completion item in the completion suggestion list, the completion item is inserted at the current cursor position.

[0102] When a user selects an item from the completion suggestion list using the keyboard or mouse, the system immediately inserts that item's text at the current cursor position. For example, if a user types "va" and the list displays "var_1," and the user presses Enter to select "var_1," the system will insert "var_1" at the cursor position, overwriting the previously entered "va." After the insertion is complete, the cursor will automatically move to the end of the inserted text so the user can continue entering subsequent code.

[0103] Step S102: Update the content of the current line of code and trigger a new code change event.

[0104] After the completion item is inserted, the content of the current line of code will change. The system will treat this change as a new code change event, recording the code snippet before the change (i.e., the part manually entered by the user) and the code snippet after the change (i.e., the complete content after the completion item is inserted). This recording process is similar to steps S1 and S2, ensuring that subsequent syntax analysis and completion library updates are based on the latest code state. For example, if the user inserts "var_1" through completion, the changed code snippet will contain "var_1". If the user subsequently modifies this line of code, the system will perform difference judgment and processing based on this latest state.

[0105] In one embodiment, the step S11, which involves recording a custom identifier entered by the user in response to the user's ignore operation of the code completion suggestion, specifically includes steps S111 to S113.

[0106] Step S111: Detect whether the user ignored the autocomplete suggestion list when completing the operation by input.

[0107] Once the system displays the autocomplete suggestion list, it continuously monitors the user's actions. If the user doesn't select any item from the list but completes the input directly by pressing Enter or moving the cursor, the system determines that the user ignored the autocomplete suggestions. For example, if the user types "newVar" and immediately presses Enter or moves the cursor, the system will record this ignored action and proceed to the subsequent custom identifier recognition process.

[0108] In step S112, if an ignore operation is detected, the complete string manually entered by the user is recorded.

[0109] After confirming that the user ignored the completion suggestions, the system records the complete string manually entered by the user. This complete string is usually a continuous sequence of characters before the cursor, ending at the Enter key or when the cursor is moved. For example, if the user enters "newVar" and presses Enter or moves the cursor, the system will record "newVar" as the complete string. This record provides the basic data for subsequent syntax analysis.

[0110] Step S113: The complete string is used as a new code fragment to trigger the code change capture mechanism.

[0111] The recorded complete string is treated as a new code snippet. The system triggers a code change capture mechanism similar to step S2, recording the state of the current code line before and after the change. Subsequently, the system performs difference analysis and syntax analysis on the new code snippet, following the process in steps S3 to S7. If the analysis results indicate that this is a new custom identifier definition, such as "Integer newVar", then "newVar" will be added to the code completion library. In this way, the system can dynamically learn new identifiers manually entered by the user, ensuring that the coverage of the completion library is continuously expanded.

[0112] In one embodiment, after automatically completing the code input in step S10, step S103 is further included.

[0113] Step S103: Check if the inserted completion item is a function name. If so, automatically generate parameter placeholders for the function call.

[0114] When a user selects a function name as the completion option, the system further checks whether that function name is associated with parameter information in the completion library. If the function definition includes parameters, the system will automatically generate a call format containing parameter placeholders after inserting the function name. For example, if the user selects "fun_2", and "fun_2" has the parameter "var_2As Integer" in its definition, the system will insert "(var_2)" immediately after inserting "fun_2" and position the cursor at the first parameter position so that the user can directly enter the parameter value. This feature of automatically generating parameter placeholders helps users quickly construct correct function call statements and reduces syntax errors.

[0115] In one embodiment, the dynamic update of the code completion library in step S11 further includes step S114.

[0116] Step S114: Code management in the code completion library is performed as follows.

[0117] When the user sets the project "Project1" as the active project, the IDE will traverse the contents of each program file (Main, Action Program, Cylinder Action, Communication, etc.) in the program folder and add the user-defined functions, parameters, and variables to the code completion library.

[0118] When a user switches to an active project, the IDE calls the `clearUserVarAndFunc()` interface function of the code completion library to clear all user-defined functions, parameters, and variables. It then iterates through the new project again, adding the new project's functions, parameters, and variables to the code completion library, and this process repeats.

[0119] In one embodiment, the provision of code completion suggestions in step S9 further includes step S93.

[0120] Step S93: Dynamically adjust the classification display of autocomplete suggestions based on the syntax type of the code currently entered by the user.

[0121] When displaying the completion suggestion list, the system categorizes the completion items based on the syntax type of the code the user is currently entering. For example, if the user is currently writing a variable assignment statement, the system will group variable name completion items at the top of the list, while function name completion items will be grouped at the bottom. If the user is writing a function call statement, function name completion items will be grouped first. This categorized display method helps users quickly locate the completion items that match their current syntax requirements, improving the intuitiveness of the completion suggestions.

[0122] In one embodiment, after automatically completing the code input in step S10, step S104 is further included.

[0123] In step S104, if the inserted completion item is a variable name, the system automatically detects whether the current line of code requires a type declaration and completes the type declaration part.

[0124] In some cases, the user selects a variable name for auto-completion, while the current line of code might be a statement that requires an explicit declaration of the variable's type. For example, if a user selects the variable "var_1" when writing a parameter passing statement, and "var_1" is defined as "Integer", the system will check the syntax structure of the current line of code. If it finds that a type declaration is required, the system will automatically insert "As Integer" after "var_1" and move the cursor to the appropriate position. This automatic type declaration completion feature helps users quickly build syntactically correct code, reducing the amount of manual typing required.

[0125] In one embodiment, the dynamic update of the code completion library in step S11 further includes step S115.

[0126] Step S115: In response to the user's batch modification operation on the code file, batch update the custom identifiers in the code completion library.

[0127] In actual programming, users may make batch modifications to code files, such as changing multiple variable names or function names at once using the find and replace function. The system will detect such batch modification operations and trigger a batch update process. Specifically, the system will traverse all modified lines of code, record the state before and after the change for each line, and then perform batch syntax analysis and completion library update operations according to steps S4 to S7. For example, if the user replaces all instances of "var_1" with "data_1", the system will first remove "var_1" from the completion library and then add "data_1" to it. Through this batch update mechanism, the system can efficiently handle large-scale code changes, ensuring that the completion library remains consistent with the code content.

[0128] In one embodiment, after the automatic completion of code input in step S10, step S105 is further included.

[0129] Step S105: Record the association between the user-selected completion item and the syntax context of the current line of code, and use it for subsequent completion suggestion optimization.

[0130] After a user selects an autocomplete option and completes their code input, the system records the association information between that autocomplete option and the syntax context of the current code line. For example, it records that "var_1" was used in an assignment statement, or "fun_2" was used in a conditional statement. This association information is stored in a history database for future autocomplete optimization. For instance, when the user writes code with similar syntax structures later, the system will refer to these history records and prioritize autocomplete options that are frequently used in similar contexts. Through this context-based learning mechanism, autocomplete suggestions can better align with the user's coding patterns.

[0131] In one embodiment, the dynamic update of the code completion library in step S11 further includes step S116.

[0132] Step S116: In response to the user's import or export operation of the code file, the custom identifier in the code completion library is updated synchronously.

[0133] In collaborative development, users may import code files written by other developers or export their own code files to others. The system will detect such import or export operations and trigger the synchronization update process of the code completion library. For import operations, engineers double-click to open the file, and the IDE will traverse the file content and add user-defined functions, parameters, and variables to the code completion library.

[0134] In one embodiment, the provision of code completion suggestions in step S9 further includes step S94.

[0135] Step S94: In response to the user's search request for completion suggestions, provide a keyword-based completion item filtering function.

[0136] When the autocomplete library is large, users may want to quickly search for specific autocomplete items using keywords. The system will respond to user search requests by providing a keyword-based filtering function. For example, if a user enters an additional keyword in the autocomplete suggestion list, the system will further filter the set of autocomplete items based on that keyword, displaying only entries containing that keyword. For instance, if a user enters "data" as the search keyword, the system will filter from the currently matching set of autocomplete items to find variable names or function names containing "data," such as "data_1" or "dataSet." This search function allows users to quickly locate specific autocomplete items, which is particularly useful in large projects.

[0137] In one embodiment, after the automatic completion of code input in step S10, step S106 is further included.

[0138] Step S106: If the inserted completion item is a function name and the function definition includes a return value type, then a placeholder for the return value receiving variable is automatically generated.

[0139] When the user selects a function name for completion, and that function specifies a return type in its definition, the system automatically generates a placeholder variable to receive the return value after inserting the function call statement. For example, if the user selects "fun_3", and "fun_3" is defined as "Function fun_3(a As Integer) As Integer", the system will automatically add a placeholder variable declaration, such as "result = fun_3(a)", before the statement after inserting "fun_3(a)", and position the cursor at the "result" position so that the user can directly modify or confirm the variable name. This feature of automatically generating a return value receiver variable placeholder helps users quickly construct complete function call statements, ensuring the integrity of the code logic.

[0140] In one embodiment, after automatically completing the code input in step S10, step S107 is further included.

[0141] Step S107: Check the syntax integrity of the current line of code. If there are syntax errors, provide repair suggestions.

[0142] After inserting completion items, the system checks the syntax integrity of the current line of code to determine if there are any obvious syntax errors. For example, if a user inserts a function name "fun_2" but fails to provide the necessary parameters, the system will detect the missing parameter syntax error and provide suggestions for correction, such as displaying a prompt box next to the cursor suggesting that the user enter parameter values ​​or use placeholders. This syntax integrity detection and correction suggestion feature helps users identify and correct errors in a timely manner while writing code, improving code quality.

[0143] Finally, it should be emphasized that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the present invention can have various changes and modifications. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for dynamic recognition and completion of user-defined identifiers based on SPEL, characterized in that, The method includes the following steps: S1. Real-time monitoring of user input or modification operations on SPEL language code in the integrated development environment; S2. When the user finishes editing the current line of code and leaves the line, obtain the code snippets before and after the editing of the line of code, define the code snippet before editing as the first code snippet, and define the code snippet after editing as the second code snippet; S3. Compare the first code segment with the second code segment to determine the changed code content; S4. Based on the preset SPEL language syntax regular expression, perform syntax type judgment and parsing on the second code segment to identify the user-defined identifier declaration contained therein; S5. When a user-defined identifier declaration is identified, the corresponding identifier name is extracted from the second code snippet and dynamically added to the code completion candidate library. S6. When it is detected that a user-defined identifier declaration has been modified or deleted, remove the corresponding invalid identifier name from the code completion candidate library; S7. The contents of the code completion candidate library are called in real time when the user subsequently inputs SPEL language code, so as to realize dynamic and context-dependent automatic completion suggestions for user-defined identifiers.

2. The method as described in claim 1, characterized in that, Step S1 also includes the following steps: S11. Before the user starts editing a line of code, the current code content of that line is pre-cached as the first code fragment; S12. When the user moves the text cursor away from the current editing line, cache the final code content of that line as the second code fragment.

3. The method as described in claim 1, characterized in that, The S3 steps are as follows: S31. Compare the first code segment and the second code segment character by character to determine whether there is a difference between them. If there is a difference, trigger step S4.

4. The method as described in claim 1, characterized in that, The S4 steps are as follows: S41. Simultaneously use SPEL user-defined variable declaration syntax regular expressions and SPEL user-defined function declaration syntax regular expressions to match the second code snippet; S42. When only the regular expression for the SPEL user-defined variable declaration syntax is successfully matched, it is determined to be a variable declaration; S43. When the regular expression for the SPEL user-defined function declaration syntax is successfully matched, it is determined to be a function declaration.

5. The method as described in claim 4, characterized in that, When a variable declaration is identified, the corresponding identifier name is extracted from the second code snippet and dynamically added to the code completion candidate library. Specifically: S421. Use the SPEL user-defined variable declaration syntax regular expression to match the iterator and obtain the matched identifiers one by one. S422. Determine whether the first matching item of the iterator belongs to the preset SPEL language data type keyword set; S423. When it belongs to the set of data type keywords, the legal identifiers subsequently matched by the iterator are added to the code completion candidate library as user-defined variable names in turn.

6. The method as described in claim 4, characterized in that, When the code snippet is identified as a function declaration, the corresponding identifier name is extracted from the second code snippet and dynamically added to the code completion candidate library. Specifically: S431. Extract function names using SPEL user-defined function declaration syntax regular expressions and add the function names to the code completion candidate library; S432. Obtain the parameter list content through the SPEL user-defined function declaration syntax regular expression; S433. Use independent parameter matching regular expressions to split the contents of the parameter list one by one, extract the identifier name of each parameter in turn, and add each parameter name to the code completion candidate library.

7. The method as described in claim 1, characterized in that, The S6 steps are as follows: S61. For the modified or deleted variable declaration line, use the SPEL user-defined variable declaration syntax regular expression to match the first code segment, extract the original variable name, and remove the corresponding variable name from the code completion candidate library. S62. For the modified or deleted function declaration line, use the SPEL user-defined function declaration syntax regular expression to match the first code segment, extract the original function name and all parameter names, and remove the corresponding function name and all related parameter names from the code completion candidate library.

8. The method as described in claim 1, characterized in that, The code completion candidate library includes at least three independent subsets: a set of user-defined variables, a set of user-defined functions, and a set of user-defined function parameters.

9. The method as described in claim 1, characterized in that, The S7 steps are as follows: S71. During the user's code input process, when the input characters reach the preset threshold or the completion shortcut key is triggered, retrieve all user-defined variable names, function names, and valid formal parameter names within the current function scope that match the current input prefix from the code completion candidate library; S72. The search results are sorted according to preset priority rules and then presented to the user.

10. A system for implementing the method as described in any one of claims 1 to 9, characterized in that, The system includes: The code change monitoring module (1) is used to monitor the user's input or modification operations on SPEL language code in the integrated development environment in real time, and when the user finishes editing the current line of code and the cursor leaves the line, it obtains the first code segment before the line of code is edited and the second code segment after the line of code is edited. The difference comparison module (2) is used to compare the first code segment with the second code segment to determine whether there are differences in code content; The syntax parsing module (3) is used to perform syntax type judgment and parsing on the first code segment and the second code segment respectively according to the preset SPEL language syntax regular expression when there are differences; The code completion library update module (4) is used to perform the following operations based on the parsing results of the syntax parsing module: When the second code snippet is identified as containing a user-defined identifier declaration, the corresponding identifier name is extracted from the second code snippet and dynamically added to the code completion candidate library; When the first code snippet is identified as containing a user-defined identifier declaration that has been modified or deleted, the corresponding invalid identifier name is removed from the code completion candidate library; The code completion suggestion module (5) is used to call the contents of the code completion candidate library in real time when the user subsequently inputs SPEL language code, so as to provide the user with dynamic and context-dependent automatic completion suggestions for user-defined identifiers.

Images