Code checking method and device and computer program product

Abstract

The invention discloses a code checking method and device and a computer program product, and relates to the technical field of computers. The method comprises the steps that according to a preset coding rule, a code checking rule is configured, and the preset coding rule is constructed based on the personalized requirement of a user; obtaining a trigger instruction of the checking operation, wherein the trigger instruction comprises a request parameter and a trigger state; in response to the trigger instruction, obtaining a target file; and checking the target file based on the code checking rule to obtain a checking result. The technical problem that in the prior art, a code checking tool cannot meet requirements is solved.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a code checking method, device and computer program product. Background Art

[0002] At present, with the continuous development of software technology, enterprises have their own requirements for coding rules. Developers have different ability levels and coding styles, resulting in differences in code readability. As a multi-center, cross-regional R&D system, and as an enterprise that attaches great importance to production safety, writing standardized code is the basis. Unified code standards can improve the readability, maintainability and scalability of the code, improve the team's collaboration ability, and help developers quickly find problems.

[0003] Commonly used Java code static rule scanning tools include: SonarQube, Checkstyle, PMD, FindBugs. Although these tools can meet the code specification scanning and PMD can support custom rules, they contain too many rules and cannot enable developers to focus on the coding rules that the enterprise is concerned about.

[0004] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0005] The embodiments of the present invention provide a code checking method, device and computer program product to at least solve the technical problem that the code checking tools in the prior art cannot meet the requirements.

[0006] According to one aspect of an embodiment of the present invention, a code checking method is provided, including: configuring code checking rules according to preset coding rules, wherein the preset coding rules are constructed based on user personalized requirements; obtaining a trigger instruction for the checking job, the trigger instruction including a request parameter and a trigger status; obtaining a target file in response to the trigger instruction; and checking the target file based on the code checking rules to obtain a checking result.

[0007] Furthermore, based on the code checking rules, the target file is checked, and after the inspection result is obtained, it includes: in response to the inspection result indicating that the target file does not comply with the code checking rules, based on the inspection result, generating problem information; based on the problem information, generating a display interface, the display interface including a plurality of preset function controls, wherein the preset function controls are controls for editing the display interface, and the display interface is at least used to display the problem information.

[0008] Furthermore, configuring code checking rules includes: defining the checking rules to obtain rule definitions; determining error levels in the code checking rules according to the rule definitions, wherein the rule definitions include: file layout rules, header comment rules, class layout rules, class comment rules, function comment rules, variable comment rules, function parameter rules, and unit test file rules, and the error levels include: level one errors, level two errors, level three errors, level four errors, and level five errors; determining code checking rules according to the rule definitions and error levels.

[0009] Furthermore, based on the code checking rules, the target file is checked to obtain the inspection result, including: in response to the request parameters in the trigger instruction, determining the file type of the target file, wherein the request parameters include: file directory, inspection rule level, whether to check unit tests, and inspection result object; in response to the target file satisfying the first preset condition, based on the code checking rules, the source code of the target file is checked to obtain the inspection result.

[0010] Furthermore, based on the code checking rules, the target file is checked to obtain the inspection result, including: in response to the request parameters including the unit test inspection, based on the code checking rules, the unit test file corresponding to the source code of the target file is checked to obtain the unit test file inspection result; the unit test file inspection result is combined with the inspection result to update the inspection result.

[0011] Furthermore, obtaining a trigger instruction for the inspection job includes: setting the inspection rule level in the trigger instruction to obtain a first setting parameter; setting whether to check the unit test in the trigger instruction to obtain a second setting parameter; setting whether to check according to the file modification time in the trigger instruction to obtain a third setting parameter; determining the request parameter based on the first setting parameter, the second setting parameter and the third setting parameter.

[0012] Further, in response to the trigger instruction, obtaining the target file includes: obtaining the target object; in response to the target object satisfying the second preset condition and the request parameter including a modification time check, determining the target file, wherein the target file is a file whose latest modification time is at or after the preset time.

[0013] Furthermore, based on the inspection results, a display interface is generated, including: in response to an operation on the problem information of the display interface, error location information is obtained, the error location information is the location information of the error text in the target file, and the error text is the text in the target file that does not comply with the code inspection rules; based on the error text in the target file and the code inspection rules, prompt modification template information is generated, the prompt modification template information is text information that complies with preset inspection rules; based on the location information and the prompt modification template information, a first display interface in the display interface is generated, the first display interface is a display interface for displaying error text, problem information and prompt modification template information.

[0014] Further, after generating the display interface based on the inspection result, the method includes: determining a selected object in response to an operation action on a display object of the display interface;

[0015] In response to an operation on a refresh control in a preset function control of the display interface, a selected object is checked based on a code checking rule to obtain a refreshed check result, and based on the refreshed check result, a second display interface in the display interface is generated, where the second display interface is a display interface after the refreshed check result;

[0016] and / or,

[0017] In response to the operation of the delete control in the preset function control of the display interface, the inspection result corresponding to the selected object is deleted to obtain the inspection result after deletion. Based on the inspection result after deletion, a third display interface in the display interface is generated. The third display interface is the display interface after the inspection result after deletion.

[0018] Furthermore, based on the inspection results, after the display interface is generated, it includes: in response to the operation action of the auxiliary control in the preset function control of the display interface, based on the preset AI model, generating supplementary text, wherein the supplementary text is used to provide modification prompts for the code at the error location; based on the supplementary text, generating supplementary display information in the display interface.

[0019] According to another aspect of an embodiment of the present invention, a code checking device is also provided, including: a configuration module, which configures code checking rules according to preset coding rules, wherein the preset coding rules are constructed based on user personalized needs; a first acquisition module, which obtains a trigger instruction for an inspection job, wherein the trigger instruction includes a request parameter and a trigger status; a second acquisition module, which obtains a target file in response to the trigger instruction; and an inspection module, which inspects the target file based on the code inspection rules to obtain an inspection result.

[0020] According to another aspect of an embodiment of the present invention, a computer program product is provided, including a computer program. When the computer program is executed by a processor, the method in each embodiment of the present invention is implemented.

[0021] In an embodiment of the present invention, preset coding rules based on personalized user requirements are adopted to obtain inspection results by checking the target file, thereby improving the standardization and efficiency of code writing, and further achieving the technical effect of ensuring that the code quality meets the requirements of the internal coding specifications of the enterprise, thereby solving the technical problem that the code checking tools in the prior art cannot meet the requirements. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0023] Figure 1 is a flow chart of an optional code checking method according to one embodiment of the present invention;

[0024] Figure 2 is a flow chart of an optional code checking method according to one embodiment of the present invention;

[0025] Figure 3 is a flow chart of an optional code checking method according to one embodiment of the present invention;

[0026] Figure 4 is a structural block diagram of an optional code checking device according to one embodiment of the present invention;

[0027] Figure 5 is an architectural diagram of an optional code checking device according to one embodiment of the present invention. DETAILED DESCRIPTION

[0028] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0029] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0030] According to an embodiment of the present invention, a code checking method embodiment is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that here. In addition, the method of the present application can be integrated into the Java development tool IDEA / Ec l ipse.

[0031] The method embodiment can be executed in an electronic device or a similar computing device including a memory and a processor. Taking running on a computer terminal as an example, the computer terminal may include one or more processors (processors may include but are not limited to central processing units (CPU), graphics processing units (GPU), digital signal processing (DSP) chips, microprocessors (MCU), programmable logic devices (Field Programmable Gate Array, FPGA), neural network processors (Neural-network Processor Unit, NPU), tensor processors (TensorProcessing Unit, TPU), artificial intelligence (Artificial Intelligence, AI) type processors and other processing devices) and a memory for storing data. Optionally, the above-mentioned computer terminal may also include a transmission device, an input and output device, and a display device for communication functions. It can be understood by those of ordinary skill in the art that the above-mentioned structural description is only for illustration, and it does not limit the structure of the above-mentioned computer terminal. For example, the computer terminal may also include more or fewer components than the above-mentioned structural description, or have a configuration different from the above-mentioned structural description.

[0032] The memory can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the code checking method in the embodiment of the present invention. The processor executes various functional applications and data processing by running the computer program stored in the memory, that is, the above-mentioned code checking method is realized. The memory may include a high-speed random access memory, and may also include a 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 may further include a memory remotely arranged relative to the processor, and these remote memories may be connected to the mobile terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0033] The transmission device is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the mobile terminal. In one example, the transmission device includes a network adapter (Network Interface Controller, referred to as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device can be a radio frequency (Radio Frequency, referred to as RF) module, which is used to communicate with the Internet wirelessly.

[0034] The display device may be, for example, a touch screen type liquid crystal display (LCD) and a touch display (also referred to as a "touch screen" or "touch display screen"). The liquid crystal display may enable a user to interact with a user interface of a mobile terminal. In some embodiments, the mobile terminal has a graphical user interface (GUI), and a user may interact with the GUI by finger contacts and / or gestures on a touch-sensitive surface, wherein the human-computer interaction functions here may optionally include the following interactions: creating web pages, drawing, word processing, making electronic documents, games, video conferencing, instant messaging, sending and receiving emails, call interfaces, playing digital videos, playing digital music and / or web browsing, etc. The executable instructions for executing the above human-computer interaction functions are configured / stored in a computer program product or readable storage medium executable by one or more processors.

[0035] Figure 1 is a method according to an embodiment of the present invention, such as Figure 1 As shown, the method comprises the following steps:

[0036] Step S10, configuring code checking rules according to preset coding rules, wherein the preset coding rules are constructed based on user personalized requirements.

[0037] In step S10, first, you need to configure personalized coding rules. These rules include but are not limited to file layout, comment specifications, code style, naming specifications, etc., and the rules are divided into different levels according to the severity, such as level 1 error (Critical), level 2 error (Error), level 3 warning (Warn), level 4 information (Info) and level 5 prompt (Tips). Users can customize the specific content and level of the rules, and these settings are stored in the local cache of the development environment.

[0038] Step S12: obtaining a trigger instruction for the inspection operation, where the trigger instruction includes a request parameter and a trigger status.

[0039] In step S12, when the developer right-clicks one or more Java files or packages in IDEA (or Eclipse), a trigger instruction is generated based on the developer's operation to trigger the inspection job. The trigger instruction includes the inspection scope (single file or folder) and whether to inspect based on the modification time range of the file.

[0040] Step S14, in response to the trigger instruction, obtaining the target file.

[0041] In step S14, in response to the check instruction triggered by the user, the selected Java source code file or the associated unit test file is obtained from the development environment. If the user chooses to check based on the file modification time range, only files modified within the specified time range will be obtained.

[0042] Step S16, based on the code checking rules, checking the target file to obtain the checking result.

[0043] In step S16, the coding rule checking module is called to check the acquired target file. The checking module parses the file information, determines the file type, and applies the preset coding rules for checking. The inspection result includes a detailed description of the violation information, modification suggestions, and severity level. The result is then displayed in the "Code Standard Check Results" view of IDEA (or Eclipse), and the developer can double-click the problem to locate the relevant line in the code and make direct modifications.

[0044] Based on steps S10 to S16, preset coding rules based on user personalized needs are adopted, and the inspection results are obtained by checking the target file, thereby improving the standardization and efficiency of code writing, and thus achieving the technical effect of ensuring that the code quality meets the requirements of the internal coding specifications of the enterprise, thereby solving the technical problem that the code checking tools in the prior art cannot meet the needs.

[0045] Optionally, based on the code inspection rules, the target file is inspected, and after the inspection result is obtained, it includes:

[0046] Step S201 , in response to the inspection result indicating that the target file does not comply with the code inspection rule, problem information is generated based on the inspection result.

[0047] In step S201, when the code checking module completes the checking of the target file, it will analyze the checking results and identify all the places that do not conform to the preset coding rules. These places that do not conform to the rules will be converted into problem information, which contains the following key parts:

[0048] Problem location: Identify the specific line or section of code that violates the rule.

[0049] Problem description: Describe in detail the specific circumstances of the violation, such as missing necessary comments, non-standard naming, layout issues, etc.

[0050] Severity level: The severity of the problem is classified according to the preset coding rules, such as level 1 error (Critic), level 2 error (Error), level 3 warning (Warn), level 4 information (Info) and level 5 tips (Tips).

[0051] Suggested remediation solutions: Provide predefined remediation templates to help developers quickly understand how to remediate violations.

[0052] Step S202: Generate a display interface based on the question information, the display interface including a plurality of preset function controls, wherein the preset function controls are controls for editing the display interface, and the display interface is at least used to display the question information.

[0053] In step S202, a display interface is generated based on the problem information. The display interface is designed to provide a clear and intuitive view to help developers quickly locate and understand the problem. The display interface is usually divided into the following areas:

[0054] Problem list area: Displays all detected problems in a list or tree structure. Each problem entry includes location, description, and severity level.

[0055] Problem details area: Displays detailed information about the selected problem, including a detailed description and correction suggestions.

[0056] Correction template area: For selected issues, correction templates are displayed, providing direct code modification examples for developers to refer to and apply.

[0057] The display interface also contains multiple preset function controls for editing and operating the display interface:

[0058] Refresh control: Allows developers to refresh the inspection results of the target file to check whether the recent code modifications have solved the problem.

[0059] Delete control: Enables developers to remove resolved issues from the display interface to avoid repeated reminders.

[0060] Sorting controls: Supports sorting by line number or severity level of issues, helping developers prioritize the most critical issues.

[0061] AI-assisted controls: Integrate AI functions to provide guidance for complex or uncertain correction plans. For example, call the REST interface to interact with the AI ​​model deployed within the enterprise to obtain modification suggestions.

[0062] This display interface appears as an independent view or window in the developer's IDEA (or Ec l ipse), and its size and position are usually configurable for parallel use with other development tools or editor windows. Developers can double-click the items in the problem list to jump directly to the corresponding location in the code editor for quick corrections. In addition, the display interface provides real-time feedback to ensure that developers can continue to monitor compliance with coding standards while correcting the code.

[0063] Based on steps S201 to S202, it can effectively help developers comply with coding rules during the development process, improve code quality and maintainability, and at the same time, by integrating preset function controls and AI auxiliary functions, further improve the user experience and correction efficiency.

[0064] Optionally, configure code checking rules, including:

[0065] Step S211, defining the inspection rule to obtain a rule definition.

[0066] In step S211, the user or system administrator defines rules through the UI interface or configuration file. The rules cover many aspects, including but not limited to:

[0067] File layout rules: define the structure and layout requirements of the file, such as the ratio of code to comments, the order of code lines, indentation style, etc.

[0068] Header comment rules: Specifies the comment information that should be included at the top of the file, such as copyright information, author, creation date, etc.

[0069] Class layout rules: standardize the structural layout of the class, including class comments, member variables, method arrangement order, etc.

[0070] Class comment rules: Class comments should contain information such as the function of the class, occasions of use, the meaning of parameters, etc.

[0071] Function comment rules: The comment format and content requirements of functions or methods, including descriptions of parameters, return values, exception handling, etc.

[0072] Variable annotation rules: Variable naming rules and their annotation specifications ensure the readability of variable names and the accuracy of annotations.

[0073] Function parameter rules: Standardize the naming, type, and usage of function parameters to ensure clarity and consistency of function interfaces.

[0074] Unit test file rules: Coding standards specific to unit test files, such as naming of test cases, comments of test functions, etc.

[0075] Step S212, determine the error level in the code checking rules according to the rule definition, wherein the rule definition includes: file layout rules, header comment rules, class layout rules, class comment rules, function comment rules, variable comment rules, function parameter rules, unit test file rules, and the error levels include: level one error, level two error, level three error, level four error and level five error.

[0076] In step S212, after defining the rules, an error level needs to be set for each rule to reflect its importance and severity in the coding specification. The error levels can be divided into:

[0077] Level 1 error (Critic): The most serious violation may cause the code to fail to compile or run normally and must be corrected immediately.

[0078] Level 2 Error: A serious violation that may affect the performance or security of the code and needs to be corrected as soon as possible.

[0079] Level 3 error (Warn): Warning violation, which may affect the readability and maintainability of the code, and correction is recommended.

[0080] Level 4 error (Info): Informational violation, usually used to provide coding style suggestions and improve code quality, with a lower priority for correction.

[0081] Level 5 Errors (Tips): Minor or suggestive violations, usually used to optimize the code, such as providing more concise writing suggestions, and have the lowest priority for correction.

[0082] Step S213, determining the code checking rules according to the rule definition and the error level.

[0083] In step S213, based on the rule definitions and error levels, the system generates the final code inspection rule set. The rule set contains detailed descriptions of all custom rules and corresponding error levels, which will serve as the basis for the code inspection module to scan the code. When scanning the file, the inspection module will analyze the code against the definitions and levels in the rule set, identify any non-compliance, and mark and classify them according to their severity.

[0084] Based on steps S211 to S213, the flexibility and pertinence of code checking are ensured, allowing enterprises or individuals to customize the most appropriate coding standards according to their own needs and preferences, and improve code quality through real-time monitoring and feedback through IDEA (or Eclipse) plug-ins.

[0085] Optionally, based on the code checking rules, the target file is checked to obtain the checking results, including:

[0086] Step S221, in response to the request parameters in the trigger instruction, determine the file type of the target file, wherein the request parameters include: file directory, check rule level, whether to check unit test, and check result object.

[0087] In step S221, when a trigger instruction is received, the request parameters are first parsed, which usually include the following information: File directory: identifies the directory of the project or folder, from which the target file will be scanned. Check rule level: defines the level of detail of the check, that is, according to which level of coding rules the check is performed, such as one or more of level 1 error (Critical), level 2 error (Error), level 3 warning (Warn), level 4 information (Info) and level 5 prompt (Tips). Whether to check unit tests: indicates whether the unit test files related to the source files should be checked at the same time. Check result object: used to store and manage the results after the check, including problem information, problem location, severity level, etc.

[0088] According to the obtained file directory, the files in the directory are traversed to find all the files that meet the requirements, and then determine whether the type of each file is Java or a related unit test file. If the file type does not match, the file will not be checked and will be skipped directly or a non-applicable response will be returned. In this way, you can focus on checking Java files to ensure the efficiency and accuracy of the inspection process.

[0089] Step S222, in response to the target file satisfying the first preset condition, based on the code checking rule, checking the source code of the target file to obtain a checking result.

[0090] In step S222, for the target file determined to be of Java type, the source code of the file is analyzed based on the custom code checking rules. This process includes: Parsing the source code: First, parse the source code of the target file to understand its structure and syntax. Applying the inspection rules: According to the rules determined in step S213, check whether the source code complies with each coding specification. Generate inspection results: For each code that does not comply with the specifications, generate problem information, including problem description, location and severity level (error level). If the request parameters include "Whether to check unit tests" and this option is selected, the unit test files related to the source file will also be checked, and the unit test file rules will be used for inspection. Finally, the inspection results will be returned in the form of an inspection result object, which contains all identified problems and their detailed information.

[0091] Based on steps S221 and S222, the coding standards are accurately applied, and personalized code quality feedback is provided for the specific type of the target file and the configuration of the request parameters. By responding to specific trigger instructions and parameters, real-time coding guidance can be provided to developers, thereby improving code quality and development efficiency.

[0092] Optionally, based on the code checking rules, the target file is checked to obtain the checking results, including:

[0093] Step S231, in response to the request parameter including checking unit test, based on the code checking rule, checking the unit test file corresponding to the source code of the target file to obtain the unit test file checking result.

[0094] In step S231, when the request parameter includes the instruction of "check unit test", the unit test file related to the target Java source file is further processed. This process is based on the unit test file rule, and the logic of checking the unit test file is as follows:

[0095] Identify unit test files: The plug-in searches for unit test files that match the target Java source files. These files are usually located in a specific directory of the project, such as "src / test / java", and follow certain naming conventions, for example, "Test.java" or "*Test.java" as the file name.

[0096] Apply inspection rules: Similar to the process of checking source code, the plug-in will check whether the unit test file follows the header comment rules, layout rules, comment specifications, naming rules, etc., to ensure that the unit test itself also meets the coding standards.

[0097] Generate unit test file inspection results: Generate problem information for each violation of the unit test file, including problem description, location and severity level (error level). This information will be collected and stored, ready to be combined with the source code inspection results.

[0098] Step S232, combining the unit test file inspection result with the inspection result to update the inspection result.

[0099] In step S232, the inspection results of the unit test files are combined with the inspection results of the existing source code to form a complete and unified inspection report. This process includes:

[0100] Result overlay: Add the problem information in the unit test file inspection results to the overall inspection result list to ensure that the problem information is not missed.

[0101] Unified display: The inspection results are displayed uniformly in the view, with source code problems and unit test file problems displayed side by side, making it easy for developers to see all violations at a glance.

[0102] Issue filtering: Based on the inspection rule level, all issues that meet the user's concern level are filtered out, whether they come from source code or unit test files.

[0103] Update local cache: Update the combined inspection results to the plug-in's local cache, ensuring that the latest inspection status can be quickly loaded the next time you view it without rescanning.

[0104] Based on step S232, by combining the inspection results of the unit test files with the source code results, developers can obtain more comprehensive code quality feedback, ensuring that both the functional code and the test code maintain high standards of standardization, thereby enhancing the maintainability of the entire code base. This approach helps the team establish a comprehensive coding standard execution system including unit testing.

[0105] Combination Figure 2 As shown, in one embodiment of the present application, a code checking method is provided, comprising the following steps:

[0106] Step S10, configuring code checking rules according to preset coding rules, wherein the preset coding rules are constructed based on user personalized requirements.

[0107] Step S12: obtaining a trigger instruction for the inspection operation, where the trigger instruction includes a request parameter and a trigger status.

[0108] Step S14, in response to the trigger instruction, obtaining the target file.

[0109] Step S221, in response to the request parameter in the trigger instruction, determine the file type of the target file,

[0110] Step S222, in response to the target file satisfying the first preset condition, based on the code checking rule, checking the source code of the target file to obtain a checking result.

[0111] Step S201 , in response to the inspection result indicating that the target file does not comply with the code inspection rule, problem information is generated based on the inspection result.

[0112] Step S231, in response to the request parameter including checking unit test, based on the code checking rule, checking the unit test file corresponding to the source code of the target file to obtain the unit test file checking result.

[0113] Step S232, combining the unit test file inspection result with the inspection result to update the inspection result.

[0114] Step S202: Generate a display interface based on the question information, the display interface including a plurality of preset function controls, wherein the preset function controls are controls for editing the display interface, and the display interface is at least used to display the question information.

[0115] Through the above steps, not only can the inspection rules be customized according to the user's personalized needs, but the inspection of source code and unit test files can also be fully covered. Finally, the user can easily manage the inspection results through an intuitive display interface. These steps ensure that the plug-in tool can adapt to different scenarios and needs, and improve code quality and development efficiency.

[0116] Optionally, obtaining a trigger instruction for the inspection job includes:

[0117] Step S241, setting the inspection rule level in the trigger instruction to obtain a first setting parameter.

[0118] In step S241, before triggering the code checking operation, you can select the coding rule level you want to check. This can be one or more of level 1 error (Critical), level 2 error (Error), level 3 warning (Warn), level 4 information (Info) and level 5 prompt (Tips). The user's selection will be used as the first setting parameter to indicate the severity of the problem that the plug-in should pay attention to during the check.

[0119] Step S242, setting whether to check the unit test in the trigger instruction to obtain a second setting parameter.

[0120] In step S242, it can also be decided whether to check the unit test files related to the source code at the same time. If "check unit test" is selected, the corresponding test files will be checked at the same time as the source code to ensure that the test code also complies with the coding specification. This setting becomes the second setting parameter.

[0121] Step S243, setting whether to check according to the file modification time in the trigger instruction to obtain a third setting parameter.

[0122] In step S243, another configurable parameter is whether to limit the inspection scope according to the modification time of the file. If "Inspect by file modification time" is selected, only files modified within the specified time range will be inspected, which helps to reduce the number of files inspected and improve inspection efficiency. This setting constitutes the third setting parameter.

[0123] Step S244: Determine the request parameter according to the first setting parameter, the second setting parameter and the third setting parameter.

[0124] In step S244, after completing the configuration of the above three setting parameters, the final request parameters are determined based on these three parameters. The request parameters usually include: Check rule level: that is, the first setting parameter, which defines the level of detail of the inspection. Whether to check unit tests: that is, the second setting parameter, indicating whether the plug-in should also check test files. Whether to check by file modification time: that is, the third setting parameter, used to determine the scope of files to be checked. Once the request parameters are determined, the plug-in can start executing the inspection job, analyze the code according to the rules and scope set by the user, and generate inspection results. This setting provides flexibility in inspection jobs, allowing developers to customize inspection strategies based on current development tasks and code status, thereby improving development efficiency and code quality.

[0125] Based on steps S241 to S244, it is possible to intelligently respond to user needs and perform customized code checks to ensure that the code is not only functionally correct but also meets high standards in terms of standardization and readability. This parameterized setting-based check strategy is one of the key means to improve the efficiency of software development project management and maintenance.

[0126] Optionally, in response to the trigger instruction, obtaining the target file includes:

[0127] Step S251, obtaining the target object.

[0128] In step S251, when the developer or system triggers the code standard checking plug-in in IDEA (or Eclipse), the target object is first obtained. The target object can be a single Java source file, a folder (containing multiple files), or the entire project. The process of obtaining the object may be triggered by the right-click menu, shortcut keys, or automatic build process, depending on the user's operation and the configuration of the plug-in.

[0129] Step S252, in response to the target object satisfying the second preset condition and the request parameter including the modification time check, determining the target file, wherein the target file is a file whose latest modification time is at or after the preset time.

[0130] In step S252, after the target object is obtained, the final target file is determined according to the second preset condition and whether the request parameter contains "modification time check". The second preset condition usually involves the type of file (for example, it must be a Java file), and the "modification time check" is used to further filter the files, only checking those files that have been modified at or after the preset time. The logic of this process is as follows:

[0131] File type verification: The plug-in first verifies whether the type of the target object is an I JavaE lement object. If not, no operation is performed. If it is an I JavaE lement object, determine whether the request parameter includes "whether to check by file modification time". If so, only files that meet the time requirements (the latest modification time is at or after the preset time) are scanned and checked; if not, all files in the target object are checked.

[0132] Modification time check: If the request parameters include the option "check by file modification time", the file list will be further filtered to keep only those files whose latest modification time is after the preset time. The preset time can be the time set by the user in the plug-in property page, or the time point after the last check. The purpose of this is to reduce unnecessary checks and improve the efficiency of the check, because files that have not been modified since the last check are unlikely to have new coding standard issues.

[0133] Determine target files: Finally, the target file set to be checked is determined based on the above filtering conditions, and code standard checks are performed based on these files.

[0134] Based on steps S251 to S252, it is possible to intelligently respond to the customized needs of users, such as determining the files to be checked by file type and modification time range, thereby performing more efficient and targeted code checking. This can not only reduce the waste of resources for checking irrelevant or unmodified files, but also ensure that developers can pay attention to and correct the latest coding problems in a timely manner, which helps to continuously improve code quality and development efficiency.

[0135] Combination Figure 3 As shown, in one embodiment of the present application, a code checking method is provided, comprising the following steps:

[0136] Step S10, configuring code checking rules according to preset coding rules, wherein the preset coding rules are constructed based on user personalized requirements.

[0137] Step S12: obtaining a trigger instruction for the inspection operation, where the trigger instruction includes a request parameter and a trigger status.

[0138] Step S241, setting the inspection rule level in the trigger instruction to obtain a first setting parameter.

[0139] Step S242, setting whether to check the unit test in the trigger instruction to obtain a second setting parameter.

[0140] Step S243, setting whether to check according to the file modification time in the trigger instruction to obtain a third setting parameter.

[0141] Step S244: Determine the request parameter according to the first setting parameter, the second setting parameter and the third setting parameter.

[0142] Step S251, obtaining the target object.

[0143] Step S252, in response to the target object satisfying the second preset condition and the request parameter including the modification time check, determining the target file, wherein the target file is a file whose latest modification time is at or after the preset time.

[0144] Step S222, in response to the target file satisfying the first preset condition, based on the code checking rule, checking the source code of the target file to obtain a checking result.

[0145] Step S201 , in response to the inspection result indicating that the target file does not comply with the code inspection rule, problem information is generated based on the inspection result.

[0146] Step S231, in response to the request parameter including checking unit test, based on the code checking rule, checking the unit test file corresponding to the source code of the target file to obtain the unit test file checking result.

[0147] Step S232, combining the unit test file inspection result with the inspection result to update the inspection result.

[0148] Step S202: Generate a display interface based on the question information, the display interface including a plurality of preset function controls, wherein the preset function controls are controls for editing the display interface, and the display interface is at least used to display the question information.

[0149] Through the above steps, not only can the inspection rules be customized according to the user's personalized needs, but the inspection of source code and unit test files can also be fully covered. Finally, the user can easily manage the inspection results through an intuitive display interface. These steps ensure that the plug-in tool can adapt to different scenarios and needs, and improve code quality and development efficiency.

[0150] Optionally, based on the inspection results, a display interface is generated, including:

[0151] Step S261, in response to the operation action on the problem information of the display interface, obtain error location information, the error location information is the location information of the error text in the target file, and the error text is the text in the target file that does not comply with the code checking rules.

[0152] In step S261, when the developer performs an operation on the problem information on the display interface (such as double-clicking or selecting), the corresponding error location information will be responded to and obtained. The error location information specifically refers to the specific location of the text (i.e., error text) that does not comply with the code checking rules in the target file, usually including the line number. This step allows developers to quickly locate the part of the code that needs attention and modification.

[0153] Step S262, based on the erroneous text in the target file and the code checking rules, generate a prompt to modify the template information, and prompt to modify the template information to be text information that complies with the preset checking rules.

[0154] In step S262, after the error location information is obtained, a prompt modification template information is automatically generated based on the error text in the target file and the preset code checking rules. This usually involves analyzing the error text, identifying the specific violated rules, and providing one or more correction suggestions to help developers understand the problem and correct it quickly. The prompt modification template information is a text example that complies with the preset checking rules, and the developer can directly refer to it or copy and paste it into the code for correction.

[0155] Step S263, based on the position information and the prompt template modification information, a first display interface in the display interface is generated, where the first display interface is a display interface for displaying error text, problem information and prompt template modification information.

[0156] In step S263, after obtaining the error location information and generating the prompt modification template information, a first display interface is generated, that is, an interface specifically used to display error text, problem information and modification suggestions. This interface is designed to provide intuitive and detailed feedback, help developers understand the context of coding standard issues, and provide direct modification guidance. The display interface may include the following elements: highlighting of error text, which is visually highlighted in the code editor; detailed description of problem information, including error type, severity level and rule name; prompt modification template information as a reference for developers to modify code. The whole process makes code standard checking not only a tool to inform the existence of errors, but also a tool to guide developers on how to correct errors and improve code quality. In this way, developers can get specific and timely feedback in the early stages of coding, thereby avoiding wasting time on subsequent code reviews and corrections, and significantly improving development efficiency and code consistency.

[0157] Based on steps S261 to S263, this code standard checking method based on interactive feedback is particularly suitable for large development teams, and can help unify code styles, reduce maintenance costs, and improve code readability and maintainability.

[0158] Optionally, based on the inspection results, after the display interface is generated, it includes:

[0159] Step S271, in response to an operation on a display object of the display interface, determining a selected object.

[0160] In step S271, the developer can perform various operations on the display object in the display interface, such as clicking, double-clicking, or selecting through the right-click menu of the mouse. In response to these operations, the plug-in can determine the object currently selected by the developer. The selected object can be a single problem, a group of problems, or a specific Java file in the inspection result list. This information is crucial for subsequent steps, such as refreshing the inspection results or obtaining more detailed problem information.

[0161] Step S272, in response to the operation of the refresh control in the preset function control of the display interface, the selected object is checked based on the code checking rules to obtain the refreshed inspection result, and based on the refreshed inspection result, a second display interface in the display interface is generated, and the second display interface is the display interface after the refresh inspection result.

[0162] In step S272, if the developer operates the refresh control in the preset function control on the display interface, in response to this operation, the code check is re-performed on the selected object. This refresh process is based on the currently set code check rules, which means that if the rules or file status are updated, the check results will be updated accordingly. Once the check is completed, the new check results (the refreshed check results) will be sorted and used to generate an updated version of the display interface, i.e., the second display interface. The second display interface reflects the latest code status and specification check results to ensure that the developer sees the most relevant and fresh information. After modifying a specific Java file or problem, the developer can quickly verify whether the modification is effective and whether new problems are introduced by clicking the refresh control. In this way, problems can be discovered and corrected in time during the coding stage, avoiding more complex reconstruction requirements in the later stages of the project or the code review stage, thereby improving development efficiency and code quality.

[0163] Based on steps S271 to S272, not only a static display of code inspection results is provided, but also dynamic inspection result management and updating are realized, which helps developers to continuously improve code specifications and correct errors in real time during the coding process.

[0164] Optionally, based on the inspection results, after the display interface is generated, it includes:

[0165] Step S271, in response to an operation on a display object on the display interface, determining a selected object;

[0166] Step S273, in response to the operation of the delete control in the preset function control of the display interface, delete the inspection result corresponding to the selected object to obtain the inspection result after deletion, and generate a third display interface in the display interface based on the inspection result after deletion. The third display interface is the display interface after the inspection result after deletion.

[0167] In step S273, according to the selected object, the corresponding information is searched and deleted in the locally cached inspection results. After the deletion operation is completed, the plug-in will update the locally cached inspection results to ensure that only the results that have not been deleted are retained. Based on the updated inspection results, the plug-in will generate a third display interface, which is an updated version of the display interface after the deletion operation. This new interface will only display the inspection results that have not been deleted, providing developers with a clearer view, avoiding the display interface from appearing too cluttered, and improving the readability and user experience of the interface so that developers can focus on the code problems that still exist.

[0168] Based on steps S271 and S273, by providing deletion controls and the resulting inspection result management capabilities, the plug-in allows developers to selectively remove certain inspection results according to their needs and project status, reduce unnecessary interference, and focus on remaining code issues.

[0169] Optionally, based on the inspection results, after the display interface is generated, it includes:

[0170] Step S274, in response to the operation action on the auxiliary control in the preset function control of the display interface, generate supplementary text based on the preset AI model, wherein the supplementary text is used to provide modification prompts for the code at the error location.

[0171] In step S274, when the developer performs an operation on the auxiliary control in the preset function control (for example, a button marked as "Assisted AI Coding") on the display interface, the plug-in responds to this operation and starts the AI ​​auxiliary function. The specific process is as follows:

[0172] First, determine the code error location that the developer is currently concerned about, which is usually based on the problem information selected on the display interface. Based on the code content and context of the error location, call the preset AI model for analysis. The AI ​​model is trained to understand the code context and provide modification suggestions for specific coding problems. After the AI ​​model analyzes, it will generate supplementary text, which is the specific text that provides modification suggestions for the code at the error location. These supplementary texts are direct modification prompts provided by the AI ​​model to developers based on the code patterns, best practices, and coding rules it has learned.

[0173] Step S275: Generate supplementary display information in the display interface based on the supplementary text.

[0174] In step S275, once the AI ​​model provides supplementary text, supplementary display information is generated based on the text. This information is usually presented in an intuitive way on the display interface to assist developers in understanding the modification suggestions given by AI and applying them to the code. The presentation of supplementary display information may include: displaying the modification suggestions provided by AI next to or below the error text on the display interface, so that developers can view detailed modification prompts without leaving the current view; providing a special area or window for displaying supplementary text, which may contain multiple modification suggestions and explanations, and developers can choose appropriate suggestions according to their needs; integrating modification suggestions for auxiliary AI coding functions, which may directly guide developers on how to modify the code through highlighting, code snippet insertion, or pop-up prompts in the code editor.

[0175] Based on steps S274 to S275, not only static code analysis results based on custom coding rules are provided, but also dynamic AI-assisted functions are introduced to provide developers with additional guidance and suggestions when correcting coding problems. This not only helps to improve code quality, but also speeds up the development process and reduces rework and code review time caused by coding standard issues.

[0176] Optionally, based on the inspection results, after the display interface is generated, it includes:

[0177] In step S276, the following steps are included: first determine the preset sorting rule selected by the developer. This can be sorting by problem severity, sorting by file name, sorting by line number where the problem first appears, etc., depending on the plug-in design and user needs; based on the selected sorting rule, the plug-in will reorganize the inspection results in the local cache. For example, if you choose to sort by problem severity, the inspection results will be rearranged from the most serious Critical level (level 1 error) problem to the mildest Tips level (level 5 error) problem; after the sorting process is completed, the plug-in will store the sorted inspection results in the local cache to ensure the accuracy of subsequent display; based on the sorted inspection results, the plug-in generates a fourth display interface, that is, an updated version of the display interface after the sorting operation. This new interface will display the inspection result list, which is rearranged according to the selected sorting rule, so that developers can browse and handle code problems more intuitively and efficiently.

[0178] By providing sorting controls and corresponding inspection result management functions, it can help developers organize inspection results according to the priority of the problem, the organizational structure of the file, or other preset rules, so as to deal with problems in an orderly manner and improve the efficiency and effectiveness of code standard inspection. In addition, the sorting function makes the display interface more user-friendly. Developers can adjust the display order of inspection results according to personal preferences or project requirements to ensure that the display interface always remains clear and orderly, which is conducive to tracking and solving code problems.

[0179] Furthermore, the inspection results are sorted based on preset sorting rules, including:

[0180] Step S277, sorting the inspection results based on the first preset rule in the preset sorting rules.

[0181] In step S277, the first preset rule is to sort by error level, and the sorting steps are as follows: identify the error level of each inspection result, which can be predefined Critical (level one error), Error (level two error), Warn (level three error), Info (level four error) and Tips (level five error), representing serious violations, errors, warnings, information and tips respectively. According to the severity of the error level, the plug-in will sort the inspection result list. Usually, the sorting will be carried out in a high-to-low order, that is, starting from the Critical (level one error) level, followed by Error (level two error), Warn (level three error), Info (level four error) and Tips (level five error), ensuring that the most serious violation appears at the front of the list. The sorted inspection results will be used to update the display interface and generate a new display interface sorted by error level. This allows developers to prioritize serious violations and gradually reduce them to lighter issues, which helps to quickly fix the most important code problems and optimize code quality.

[0182] Step S278, sorting the inspection results based on the first preset rule in the preset sorting rules.

[0183] In step S278, the second preset rule is to sort according to the position information of the error text, and the sorting steps are as follows: read the position information about the error text in each inspection result. Sort the inspection results according to the position information of the error text in the target file. This usually means sorting in ascending order by line number, and if the line numbers are the same, sorting by error level. This sorting method helps developers to intuitively locate and fix problems in the code editor, especially when dealing with problems in long files or multiple files, avoiding frequent context switching. The sorted inspection results will be used to update the display interface to generate a new display interface sorted by position information. This allows developers to handle problems in the actual order in the code, improving the efficiency of code repair.

[0184] Based on steps S277 to S278, a flexible way of sorting the inspection results is provided to meet the needs of different scenarios. Whether it is dealing with problems based on severity or fixing problems based on code structure, effective support can be obtained. This not only improves the efficiency of code modification, but also enhances the user-friendliness and practicality of the code standard inspection plug-in.

[0185] According to a flowchart of another code checking method according to one embodiment of the present invention, the method comprises the following steps:

[0186] Step S201 , in response to the inspection result indicating that the target file does not comply with the code inspection rule, problem information is generated based on the inspection result.

[0187] Step S202: Generate a display interface based on the question information, the display interface including a plurality of preset function controls, wherein the preset function controls are controls for editing the display interface, and the display interface is at least used to display the question information.

[0188] Step S211, defining the inspection rule to obtain a rule definition.

[0189] Step S212, determine the error level in the code checking rules according to the rule definition, wherein the rule definition includes: file layout rules, header comment rules, class layout rules, class comment rules, function comment rules, variable comment rules, function parameter rules, unit test file rules, and the error levels include: level one error, level two error, level three error, level four error and level five error.

[0190] Step S213, determining the code checking rules according to the rule definition and the error level.

[0191] Step S221: In response to the request parameters in the trigger instruction, determine the file type of the target file, wherein the request parameters include: file directory, check rule level, whether to check unit test, and check result object.

[0192] Step S222: In response to the target file satisfying the first preset condition, based on the code checking rule, the source code of the target file is checked to obtain a checking result.

[0193] Step S231, in response to the request parameter including checking unit test, based on the code checking rule, checking the unit test file corresponding to the source code of the target file to obtain the unit test file checking result.

[0194] Step S232, combining the unit test file inspection result with the inspection result to update the inspection result.

[0195] Step S241, setting the inspection rule level in the trigger instruction to obtain a first setting parameter.

[0196] Step S242, setting whether to check the unit test in the trigger instruction to obtain a second setting parameter.

[0197] Step S243, setting whether to check according to the file modification time in the trigger instruction to obtain a third setting parameter.

[0198] Step S244: Determine the request parameter according to the first setting parameter, the second setting parameter and the third setting parameter.

[0199] Step S251, obtaining the target object.

[0200] Step S252, in response to the target object satisfying the second preset condition and the request parameter including the modification time check, determining the target file, wherein the target file is a file whose latest modification time is at or after the preset time.

[0201] Step S261, in response to the operation action on the problem information of the display interface, obtain error location information, the error location information is the location information of the error text in the target file, and the error text is the text in the target file that does not comply with the code checking rules.

[0202] Step S262, based on the erroneous text in the target file and the code checking rules, generate a prompt to modify the template information, and prompt to modify the template information to be text information that complies with the preset checking rules.

[0203] Step S263, based on the position information and the prompt template modification information, a first display interface in the display interface is generated, where the first display interface is a display interface for displaying error text, problem information and prompt template modification information.

[0204] Step S271, in response to an operation on a display object of the display interface, determining a selected object.

[0205] Step S272, in response to the operation of the refresh control in the preset function control of the display interface, the selected object is checked based on the code checking rules to obtain the refreshed inspection result, and based on the refreshed inspection result, a second display interface in the display interface is generated, and the second display interface is the display interface after the refresh inspection result.

[0206] Step S273, in response to the operation of the delete control in the preset function control of the display interface, delete the inspection result corresponding to the selected object to obtain the inspection result after deletion, and generate a third display interface in the display interface based on the inspection result after deletion. The third display interface is the display interface after the inspection result after deletion.

[0207] Step S274, in response to the operation action on the auxiliary control in the preset function control of the display interface, generate supplementary text based on the preset AI model, wherein the supplementary text is used to provide modification prompts for the code at the error location.

[0208] Step S275: Generate supplementary display information in the display interface based on the supplementary text.

[0209] Step S276: In response to the operation of the sorting control in the preset function control of the display interface, the inspection results are sorted based on the preset sorting rules, and based on the sorted inspection results, a fourth display interface in the display interface is generated, and the fourth display interface is the display interface after the sorted inspection results.

[0210] Based on the above steps S201 to S276, in an embodiment of the present invention, not only can code checking be performed according to custom rules, but the inspection results can also be efficiently managed through a graphical interface, and the AI ​​model can be used to assist developers in code modification, thereby improving code quality and development efficiency, thereby solving the technical problem that code checking tools in the prior art cannot meet the needs.

[0211] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, a magnetic disk, or an optical disk), and includes a number of instructions for enabling a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in each embodiment of the present invention.

[0212] In an embodiment of the present invention, a code checking device is also provided, which is used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions that have been made will not be repeated. As used below, the term "module" can implement a combination of software and / or hardware of a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0213] Figure 4 1 is a structural block diagram of a code checking device according to one embodiment of the present invention. Figure 4 As shown, the device comprises:

[0214] Configuration module 301, configures code checking rules according to preset coding rules, wherein the preset coding rules are constructed based on user personalized requirements;

[0215] A first acquisition module 302 acquires a trigger instruction for an inspection operation, where the trigger instruction includes a request parameter and a trigger status;

[0216] The second acquisition module 303 acquires the target file in response to the trigger instruction;

[0217] The checking module 304 checks the target file based on the code checking rules to obtain the checking result.

[0218] Optionally, the inspection module 304 is further configured to generate problem information based on the inspection result in response to the inspection result indicating that the target file does not comply with the code inspection rule. Based on the problem information, a display interface is generated, the display interface includes a plurality of preset function controls, wherein the preset function controls are controls for editing the display interface, and the display interface is at least used to display the problem information.

[0219] Optionally, the configuration module 301 is further used to define the inspection rules to obtain rule definitions; according to the rule definitions, the error levels in the code inspection rules are determined, wherein the rule definitions include: file layout rules, header annotation rules, class layout rules, class annotation rules, function annotation rules, variable annotation rules, function parameter rules, and unit test file rules, and the error levels include: level 1 error, level 2 error, level 3 error, level 4 error, and level 5 error. According to the rule definitions and error levels, the code inspection rules are determined;

[0220] Optionally, the second acquisition module 303 is also used to determine the file type of the target file in response to the request parameters in the trigger instruction, wherein the request parameters include: file directory, check rule level, whether to check unit tests, and check result objects; in response to the target file satisfying the first preset condition, based on the code check rules, the source code of the target file is checked to obtain the inspection result.

[0221] Optionally, the inspection module 304 is also used to respond to the request parameters including unit test inspection, based on the code inspection rules, to inspect the unit test file corresponding to the source code of the target file to obtain the unit test file inspection result; and combine the unit test file inspection result with the inspection result to update the inspection result.

[0222] Optionally, the first acquisition module 302 is also used to set the inspection rule level in the trigger instruction to obtain a first setting parameter; to set whether to check the unit test in the trigger instruction to obtain a second setting parameter; to set whether to check according to the file modification time in the trigger instruction to obtain a third setting parameter; and to determine the request parameter based on the first setting parameter, the second setting parameter and the third setting parameter.

[0223] Optionally, the second acquisition module 303 is further used to acquire a target object; in response to the target object satisfying a second preset condition and the request parameter including a modification time check, determine a target file, wherein the target file is a file whose latest modification time is at or after a preset time.

[0224] Optionally, the code checking device also includes a feedback module 305, which is used to obtain error location information in response to an operation on the problem information of the display interface, the error location information is the location information of the error text in the target file, and the error text is the text in the target file that does not comply with the code checking rules; based on the error text in the target file and the code checking rules, generate prompt modification template information, the prompt modification template information is text information that complies with preset checking rules; based on the location information and the prompt modification template information, generate a first display interface in the display interface, the first display interface is a display interface for displaying error text, problem information and prompt modification template information.

[0225] Optionally, the feedback module 305 is further used to determine the selected object in response to an operation on a display object of the display interface. In response to an operation on a refresh control in a preset function control of the display interface, the selected object is checked based on the code check rule to obtain a refreshed check result, and based on the refreshed check result, a second display interface in the display interface is generated, and the second display interface is the display interface after the refresh check result.

[0226] Optionally, the feedback module 305 is further used to respond to an operation on a display object of the display interface to determine the selected object. In response to an operation on a delete control in a preset function control of the display interface, the inspection result corresponding to the selected object is deleted to obtain the inspection result after deletion, and based on the inspection result after deletion, a third display interface in the display interface is generated, and the third display interface is a display interface after the inspection result after deletion.

[0227] Optionally, the feedback module 305 is further used to generate supplementary text based on a preset AI model in response to an operation on an auxiliary control in a preset function control of the display interface, wherein the supplementary text is used to provide modification prompts for the code at the error location. Based on the supplementary text, supplementary display information in the display interface is generated.

[0228] Optionally, the feedback module 305 is also used to respond to the operation of the sorting control in the preset function control of the display interface, sort the inspection results based on the preset sorting rules, and generate a fourth display interface in the display interface based on the sorted inspection results, and the fourth display interface is the display interface after the sorted inspection results.

[0229] It should be noted that the above modules can be implemented by software or hardware. For the latter, it can be implemented in the following ways, but not limited to: the above modules are all located in the same processor; or the above modules are located in different processors in any combination.

[0230] Figure 5 1 is a structural block diagram of a code checking device according to one embodiment of the present invention. Figure 5 As shown, the device is an Eclipse code standard checking plug-in, including a preference property page, a menu operation function and a view function.

[0231] The preference property page configures code checking rules according to preset coding rules, where the preset coding rules are built based on user personalized needs; it is also used to obtain request parameters in the trigger instruction of the inspection job, and in response to the trigger instruction, obtain the target file (and update the local property value cache).

[0232] The menu operation function is used to obtain the trigger status in the trigger instruction of the inspection job (and obtain the target file from the local attribute value cache), and request the coding rule inspection module to inspect the target file based on the code inspection rules to obtain the inspection result.

[0233] The view function is used to generate problem information based on the inspection results in response to the inspection results indicating that the target file does not comply with the code inspection rules. Based on the problem information, a display interface is generated (and the local inspection result cache is updated). The display interface includes multiple preset function controls, wherein the preset function controls are controls for editing the display interface, and the display interface is at least used to display problem information. Operating the preset function control and performing a refresh operation will realize a re-inspection of the selected content. Operating the preset function control and performing a delete / sort operation will realize the deletion / sorting of the inspection results and update the local inspection result cache.

[0234] According to one embodiment of the present invention, there is further provided an electronic device, comprising: a memory storing an executable program; and a processor for running the program, wherein the above-mentioned code checking method is executed when the program is running.

[0235] Optionally, in this embodiment, the processor may be configured to perform the following steps through a computer program:

[0236] Step S10, configuring code checking rules according to preset coding rules, wherein the preset coding rules are constructed based on user personalized requirements.

[0237] Step S12: obtaining a trigger instruction for the inspection operation, where the trigger instruction includes a request parameter and a trigger status.

[0238] Step S14, in response to the trigger instruction, obtaining the target file.

[0239] Step S16, based on the code checking rules, checking the target file to obtain the checking result.

[0240] According to one embodiment of the present invention, a computer-readable storage medium is further provided. The computer-readable storage medium includes a stored executable program. When the executable program runs, the device where the storage medium is located is controlled to execute the above-mentioned code checking method.

[0241] Optionally, in this embodiment, the storage medium may be configured to store a computer program for performing the following steps:

[0242] Step S10, configuring code checking rules according to preset coding rules, wherein the preset coding rules are constructed based on user personalized requirements.

[0243] Step S12: obtaining a trigger instruction for the inspection operation, where the trigger instruction includes a request parameter and a trigger status.

[0244] Step S14, in response to the trigger instruction, obtaining the target file.

[0245] Step S16, based on the code checking rules, checking the target file to obtain the checking result.

[0246] Optionally, in this embodiment, the above-mentioned storage medium may include but is not limited to: a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and other media that can store computer programs.

[0247] According to one embodiment of the present invention, a computer program product is also provided, including a computer program, and the computer program implements the above-mentioned code checking method when executed by a processor.

[0248] Optionally, in this embodiment, the computer program product may be configured as a computer program for executing the following steps:

[0249] Step S10, configuring code checking rules according to preset coding rules, wherein the preset coding rules are constructed based on user personalized requirements.

[0250] Step S12: obtaining a trigger instruction for the inspection operation, where the trigger instruction includes a request parameter and a trigger status.

[0251] Step S14, in response to the trigger instruction, obtaining the target file.

[0252] Step S16, based on the code checking rules, checking the target file to obtain the checking result.

[0253] In the above embodiments of the present invention, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0254] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units can be a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0255] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0256] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0257] If the integrated unit is implemented in the form of 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 the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk and other media that can store program codes.

[0258] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A code checking method, characterized in that: include: Configure code checking rules according to preset coding rules, wherein the preset coding rules are constructed based on user personalized requirements; Obtaining a trigger instruction for the inspection job, wherein the trigger instruction includes a request parameter and a trigger status; In response to the trigger instruction, obtaining a target file; Based on the code checking rule, the target file is checked to obtain a checking result.

2. The method according to claim 1, characterized in that Based on the code checking rule, the target file is checked, and after obtaining the checking result, the following steps are included: In response to the inspection result indicating that the target file does not comply with the code inspection rule, generating problem information based on the inspection result; Based on the question information, a display interface is generated, wherein the display interface includes a plurality of preset function controls, wherein the preset function controls are controls for editing the display interface, and the display interface is at least used to display the question information.

3. The method according to claim 1, characterized in that Configuring the code checking rules includes: The inspection rule is defined to obtain a rule definition; According to the rule definition, determining the error level in the code checking rule, wherein the rule definition includes: file layout rules, header annotation rules, class layout rules, class annotation rules, function annotation rules, variable annotation rules, function parameter rules, and unit test file rules, and the error levels include: level 1 error, level 2 error, level 3 error, level 4 error, and level 5 error; The code checking rule is determined according to the rule definition and the error level.

4. The method according to claim 2, characterized in that: Based on the code checking rule, the target file is checked to obtain the checking result, including: In response to the request parameters in the trigger instruction, determining the file type of the target file, wherein the request parameters include: file directory, check rule level, whether to check unit test, and check result object; In response to the target file satisfying the first preset condition, the source code of the target file is checked based on the code checking rule to obtain the checking result.

5. The method according to claim 4, characterized in that Based on the code checking rule, the target file is checked to obtain the checking result, including: In response to the request parameter including checking unit test, based on the code checking rule, checking the unit test file corresponding to the source code of the target file to obtain a unit test file checking result; The unit test file inspection result is combined with the inspection result to update the inspection result.

6. The method according to any one of claims 1 to 3, characterized in that Obtaining the trigger instruction of the inspection operation includes: Setting the inspection rule level in the trigger instruction to obtain a first setting parameter; Setting whether to check the unit test in the trigger instruction to obtain a second setting parameter; Setting whether to check according to the file modification time in the trigger instruction to obtain a third setting parameter; The request parameter is determined according to the first setting parameter, the second setting parameter and the third setting parameter.

7. The method according to claim 4, characterized in that In response to the trigger instruction, obtaining the target file includes: Get the target object; In response to the target object satisfying a second preset condition and the request parameter including a modification time check, the target file is determined, wherein the target file is a file whose latest modification time is at or after a preset time.

8. The method according to claim 2, characterized in that: Generating the display interface includes: In response to an operation on the problem information of the display interface, error location information is obtained, where the error location information is location information of error text in the target file, and the error text is text in the target file that does not comply with the code checking rule; Based on the error text in the target file and the code checking rule, generating prompt modification template information, wherein the prompt modification template information is text information that complies with the preset checking rule; Based on the location information and the prompt modification template information, a first display interface in the display interface is generated, where the first display interface is a display interface for displaying the error text, the problem information and the prompt modification template information.

9. The method according to claim 2, characterized in that: After the display interface is generated based on the inspection result, the following steps are included: In response to an operation on a display object of the display interface, determining a selected object; In response to an operation on a refresh control in the preset function control of the display interface, the selected object is checked based on the code checking rule to obtain the refreshed checking result, and based on the refreshed checking result, a second display interface in the display interface is generated, where the second display interface is the display interface after refreshing the checking result; and / or, In response to an operation on a delete control in the preset function control of the display interface, the inspection result corresponding to the selected object is deleted to obtain the inspection result after deletion. Based on the inspection result after deletion, a third display interface in the display interface is generated, and the third display interface is the display interface after the inspection result after deletion.

10. The method according to claim 2, characterized in that After the display interface is generated based on the inspection result, the following steps are included: In response to an operation on an auxiliary control in the preset function control of the display interface, a supplementary text is generated based on a preset AI model, wherein the supplementary text is used to provide a modification prompt for the code at the error position; Based on the supplementary text, supplementary display information in the display interface is generated.

11. A code checking device, characterized in that: include: A configuration module, configuring code checking rules according to preset coding rules, wherein the preset coding rules are constructed based on user personalized requirements; A first acquisition module is used to acquire a trigger instruction for an inspection operation, wherein the trigger instruction includes a request parameter and a trigger status; A second acquisition module, in response to the trigger instruction, acquires the target file; The checking module checks the target file based on the code checking rule to obtain a checking result.

12. A computer program product, characterized in that It comprises a computer program which, when executed by a processor, implements the method according to any one of claims 1 to 10.

Images