Method and device for improving code quality by using Java reflection mechanism

Abstract

The invention discloses a method and a device for improving code quality by using a Java reflection mechanism, and relates to the field of code quality management. In the method, a code specification in a to-be-detected item is set, the code specification is converted into a rule set, and the code specification comprises a naming agreement, a code structure and a coding style; dynamically traversing all code elements in the item to be detected through a Java reflection mechanism, wherein the code elements comprise classes, methods and fields; checking the code elements one by one according to the rule set to judge whether the code elements conform to the code specifications or not; and when the code element does not conform to the code specification, prompting that the code element is abnormal. By implementing the technical scheme provided by the invention, the effects of automatically detecting the code quality problem and improving the code quality and the development efficiency are achieved.

Description

Technical Field

[0001] The present application relates to the technical field of code quality management, and in particular to a method and device for improving code quality by utilizing a Java reflection mechanism. Background Art

[0002] Code quality management is an indispensable part of the software development process. It is not only related to the maintainability and readability of the code, but also directly affects the quality and stability of the software product.

[0003] At present, in order to maintain the quality of the code and comply with the coding standards, developers need to spend a lot of time and energy to manually detect and maintain the code specifications, which is a very cumbersome process. At the same time, due to the increasing complexity and scale of the project, the code specifications are easily missed, resulting in a decrease in the maintainability and stability of the project.

[0004] Therefore, a more efficient way is needed to detect and fix quality issues in code. Summary of the invention

[0005] The present application provides a method and device for improving code quality by utilizing a Java reflection mechanism, which improves code quality and development efficiency by automatically detecting code quality issues.

[0006] In a first aspect of the present application, a method for improving code quality by using a Java reflection mechanism is provided, which is applied to a code detection platform. The method comprises: Set code specifications in the project to be detected and convert the code specifications into a rule set, wherein the code specifications include naming conventions, code structure and coding style; Dynamically traverse all code elements in the project to be detected through a Java reflection mechanism, wherein the code elements include classes, methods, and fields; Checking the code elements one by one according to the rule set to determine whether the code elements comply with the code specification; When the code element does not comply with the code specification, it is prompted that an exception occurs in the code element.

[0007] Optionally, setting a code specification in the project to be detected and converting the code specification into a rule set includes: Determine a regular expression according to the code specification, and determine whether there is a preset pattern in the code specification, and the preset pattern cannot be directly matched by the regular expression; When there is a preset mode in the code specification, determining the verification logic according to the preset mode; The regular expression and the validation logic are associated with corresponding check items to form a definition file, and a rule set is configured according to the definition file.

[0008] Optionally, dynamically traversing all code elements in the project to be detected by using a Java reflection mechanism further includes: Load the class file in the project to be detected by using the Java class loader according to the preset class path, and obtain the class object from the class file; Obtain the root package name in the project to be detected, and traverse each package starting from the root package name; In the process of traversing the package, for each class, the method list and field list of the class are obtained through the reflection method according to the class object; The method list and the field list are recorded in a log or data structure.

[0009] Optionally, obtaining a method list and a field list of a class by a reflection method according to the class object includes: Use Java reflection to obtain all methods and all fields of the current class; For each method, construct a unique first identifier based on the name of the method, the parameter type list, the return type, and the class name of the method, associate the first identifier with the first information of the corresponding method, and construct a method list based on the first information; For each field, a unique second identifier is constructed based on the name of the field, the field type, and the class name to which the field belongs, the second identifier is associated with the second information of the corresponding field, and a field list is constructed according to the second information.

[0010] Optionally, checking the code elements one by one according to the rule set to determine whether the code elements comply with the code specification includes: Extracting a rule subset related to the element type of the current code element from the rule set; When the element type is a class, checking whether the naming of the current code element complies with the naming convention, whether the structure complies with the code structure specification, and whether the coding style complies with the coding style requirements according to the rule subset; When the element type is a method, checking whether the naming, parameter list, return type and method body of the current code element conform to the specification according to the rule subset; When the element type is a field, checking whether the naming, type and initial value of the current code element conform to the specification according to the rule subset; If the current code element does not comply with any rule, it is determined that the current code element does not comply with the code specification.

[0011] Optionally, the prompting that the code element is abnormal includes: Generate an exception report based on the code element that does not conform to the specification, wherein the exception report includes the element type, the class name, the location in the code, the non-conforming code fragment and the violated rules; According to the exception report, the code elements that do not meet the specifications are pointed out in the code editing interface by highlighting, underlining or popping up a prompt box, and modification suggestions or repair options are provided.

[0012] Optionally, the method further includes: Setting a code quality threshold, and scoring the code quality of the project to be detected according to the code quality threshold; Generate a code quality report based on the score, wherein the code quality report includes the number and type distribution of code elements that do not conform to the specification, and historical change trends; Generate code quality improvement suggestions based on the code quality report, where the code quality improvement suggestions include the highest priority code elements that need to be corrected.

[0013] In a second aspect of the present application, a system for improving code quality by using a Java reflection mechanism is provided, comprising a rule module, a traversal module, a check module and a prompt module, wherein: A rule module is configured to set code specifications in the project to be detected and convert the code specifications into a rule set, wherein the code specifications include naming conventions, code structure and coding style; A traversal module, configured to dynamically traverse all code elements in the project to be detected through a Java reflection mechanism, wherein the code elements include classes, methods and fields; A checking module, configured to check the code elements one by one according to the rule set to determine whether the code elements comply with the code specification; The prompt module is configured to prompt that an exception occurs in the code element when the code element does not comply with the code specification.

[0014] In the third aspect of the present application, an electronic device is provided, including a processor, a memory, a user interface and a network interface, the memory is used to store instructions, the user interface and the network interface are both used to communicate with other devices, and the processor is used to execute the instructions stored in the memory so that the electronic device executes any one of the methods described above.

[0015] In a fourth aspect of the present application, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores instructions, and when the instructions are executed, any of the methods described above is executed.

[0016] In summary, one or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages: 1. By converting code specifications into rule sets and using the Java reflection mechanism to dynamically traverse all code elements (classes, methods, and fields) in the project to be tested, comprehensive and automated code testing can be achieved. Compared with manual code review, this method greatly improves detection efficiency and reduces labor costs; 2. Checking whether code elements comply with code specifications such as naming conventions, code structure, and coding style through a unified set of rules helps ensure the consistency and readability of code throughout the project. This consistency not only improves the maintainability of the code, but also reduces communication barriers and errors that may be caused by inconsistent code styles; 3. When a code element does not conform to the code specification, the embodiment of the present application can prompt an exception in time, so that the developer can quickly locate and fix the code problem. This instant feedback mechanism helps to find and solve problems in the early stage of code development, avoiding the accumulation and amplification of problems in the subsequent development and maintenance process; 4. Following the code standards helps reduce potential errors and vulnerabilities in the code, thereby improving the overall quality and security of the code. Code detection through reflection mechanism can further discover and fix problems that are missed or difficult to find due to manual review; 5. The embodiment of the present application is based on the Java reflection mechanism, so it has good adaptability and scalability. With the continuous updating and improvement of the code specifications, new specifications can be easily added to the rule set without large-scale modification of the detection logic; 6. Through unified code checking standards and processes, the embodiments of the present application help promote collaboration and standardization among team members. All members follow the same code specifications, reducing communication costs and misunderstandings caused by differences in personal styles. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 It is a flowchart of a method for improving code quality by using a Java reflection mechanism disclosed in an embodiment of the present application; Figure 2 It is a code explanation diagram of a method for improving code quality by using a Java reflection mechanism disclosed in an embodiment of the present application; Figure 3 It is a schematic diagram of executing the method for improving code quality by using the Java reflection mechanism disclosed in the embodiment of the present application; Figure 4 It is a test code snippet disclosed in the embodiment of this application; Figure 5 It is a schematic diagram of test results obtained after testing a test code snippet using the method for improving code quality using a Java reflection mechanism disclosed in an embodiment of the present application; Figure 6It is a module schematic diagram of a system for improving code quality by using a Java reflection mechanism disclosed in an embodiment of the present application; Figure 7 It is a structural schematic diagram of an electronic device disclosed in an embodiment of the present application.

[0018] Explanation of the reference numerals: 601, rule module; 602, traversal module; 603, inspection module; 604, prompt module; 701, processor; 702, communication bus; 703, user interface; 704, network interface; 705, memory. DETAILED DESCRIPTION

[0019] In order to enable technicians in this field to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this application, not all of the embodiments.

[0020] In the description of the embodiments of the present application, words such as "for example" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design described as "for example" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "for example" or "for example" is intended to present related concepts in a specific way.

[0021] In the description of the embodiments of the present application, the meaning of the term "multiple" refers to two or more. For example, multiple systems refer to two or more systems, and multiple screen terminals refer to two or more screen terminals. In addition, the terms "first" and "second" are used for descriptive purposes only and cannot be understood as indicating or implying relative importance or implicitly indicating the indicated technical features. Thus, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. The terms "include", "comprise", "have" and their variations all mean "including but not limited to", unless otherwise specifically emphasized.

[0022] This embodiment discloses a method for improving code quality by using Java reflection mechanism, which is applied to a code detection platform. Figure 1 is a flow chart of a method for improving code quality by using a Java reflection mechanism disclosed in an embodiment of the present application, such as Figure 1 As shown, the method comprises the following steps: S110, setting a code specification in the project to be detected, and converting the code specification into a rule set, wherein the code specification includes a naming convention, a code structure, and a coding style; Naming conventions refer to a set of rules that you follow when naming variables, functions, classes, modules, etc. Good naming conventions help improve the readability and maintainability of your code. Variable Naming: Use lowercase letters and underscores (snake_case) to name variables, such as user_name, order_total. Function Naming: Also use lowercase letters and underscores to name functions, such as calculate_discount, fetch_data. Class Naming: Use camelCase to name classes, such as UserProfile, OrderManager. Constant Naming: Use uppercase letters and underscores to name constants, such as MAX_RETRIES, DEFAULT_TIMEOUT. Module and Package Naming: Use lowercase letters and underscores, short and descriptive, such as database_utils, payment_gateway. Converted into a rule set: Rule 1, variable names must use lowercase letters and underscores; Rule 2, function names must use lowercase letters and underscores; Rule 3, class names must use camelCase; Rule 4, constant names must use uppercase letters and underscores; Rule 5, module and package names must use lowercase letters and underscores.

[0023] Code structure refers to the way the code is organized, including file organization, directory structure, code block division, etc. A good code structure helps to manage and expand the code. File organization: Each module or function block should have an independent file, such as user authentication related code is placed in auth.py. Directory structure: Divide the directories according to the function, such as controllers, models, views, etc., to maintain a clear hierarchy. Code block division: Use functions and classes to divide the code into logical units. Each function or class should be responsible for only one function. Comments and documentation: Add appropriate comments and documentation strings above code blocks, functions, and classes to explain their purpose and parameters. Converted into a set of rules: Rule 6, each module or function block should have an independent file; Rule 7, the directory structure should be divided according to the function and maintain a clear hierarchy; Rule 8, each function or class should be responsible for only one function; Rule 9, add appropriate comments and documentation strings above code blocks, functions, and classes.

[0024] Coding style refers to the specific way of writing code, including indentation, spaces, line breaks, etc. A unified coding style helps team members collaborate. Indentation: Use 4 spaces for indentation, and do not use tabs. Spaces: Add spaces on both sides of operators, after commas, after colons, etc., such as a = b + c, if x>0. Line breaks: The beginning and end of each code block (such as function body, loop body) should be separated by a blank line, and the code line should not exceed 80 characters. Brackets: Use brackets in complex expressions to improve readability, such as (a + b) * (c - d). Strings: Use single quotes (') or double quotes (") to surround strings, and maintain consistency, such as 'hello', "world". Converted into a rule set: Rule 10, use 4 spaces for indentation, and do not use tabs; Rule 11, add spaces on both sides of operators, after commas, after colons, etc.; Rule 12, the beginning and end of each code block should be separated by a blank line, and the code line should not exceed 80 characters; Rule 13, Use brackets in complex expressions to improve readability; Rule 14, Use single quotes or double quotes to surround strings, and maintain consistency.

[0025] Optionally, setting a code specification in the project to be detected and converting the code specification into a rule set includes: Determine a regular expression according to the code specification, and determine whether there is a preset pattern in the code specification, and the preset pattern cannot be directly matched by the regular expression; When there is a preset mode in the code specification, determining the verification logic according to the preset mode; The regular expression and the validation logic are associated with corresponding check items to form a definition file, and a rule set is configured according to the definition file.

[0026] Write the corresponding regular expressions according to the specific clauses in the code specification. Regular expressions are a powerful text matching tool that allows you to define complex patterns to match specific structures or styles in the code. For example, for variable naming specifications, you can write a regular expression to match a string that starts with a lowercase letter and is followed by any number of lowercase letters, numbers, or underscores. This regular expression can be used to check whether the variable name complies with the specification. When writing regular expressions, you may find that some clauses in the code specification cannot be matched directly by regular expressions. These clauses may involve more complex logical judgments, such as checking the number of function parameters, judging whether a code block contains specific statements, etc. For these preset patterns that cannot be matched directly by regular expressions, additional steps need to be taken to define validation logic. When there are preset patterns in the code specification that cannot be matched directly by regular expressions, additional validation logic needs to be written to handle these patterns. The validation logic can be a piece of code or script that checks whether the code complies with the specification according to the definition of the preset pattern. For example, for the limit on the number of function parameters, you can write a validation logic to check whether the number of parameters of each function exceeds the specified upper limit. This validation logic can go through all the function definitions in the code and count the number of parameters for each function. After defining the regular expression and validation logic, you need to associate them with the corresponding check items. Check items are elements in the code review tool that are used to identify and report non-compliant code. For example, you can associate a regular expression for variable naming specifications with the check item "Variable naming". When the code review tool scans the code, it uses this regular expression to check whether each variable name complies with the specification and reports an error if a non-compliant variable name is found. Similarly, for preset patterns that cannot be matched directly by regular expressions, you can associate validation logic with the corresponding check items. In this way, when the code review tool executes the validation logic, it can check whether the code complies with the specification based on the definition of the preset pattern and report an error if non-compliant code is found. Finally, you need to integrate the regular expression, validation logic, and their association with the check items into a definition file. This definition file is usually a configuration file or script that contains all the information required by the code review tool to execute the rule set. The process of configuring a rule set usually involves loading the definition file into the code review tool and setting the corresponding parameters and options to specify the rule set to execute. Once configured, the code review tool can check whether the code complies with the specifications according to the rule set and provide detailed error reports when non-compliant code is found.

[0027] Regular expressions can be used to efficiently match and detect specific patterns in the code, such as naming conventions, indentation and spaces in the code structure, etc. The powerful matching ability of regular expressions makes code detection more accurate and reduces false positives and missed detections. When there are preset patterns in the code specification that cannot be directly matched by regular expressions, verification logic can be formulated to supplement it to ensure the comprehensiveness of the detection. This detection method that combines regular expressions and verification logic improves the accuracy and efficiency of code detection. In the process of converting code specifications into rule sets, regular expressions and verification logic are associated with inspection items through definition files. This structured approach makes code specifications more flexible and can be expanded and modified according to actual needs. When it is necessary to add new code specifications or adjust existing specifications, you only need to update the relevant parts in the definition file to quickly generate a new rule set without making large-scale modifications to the entire detection system. Automated code detection tools can promptly discover and fix irregularities in the code and improve code quality. This helps reduce errors and vulnerabilities caused by irregular code and improves the stability and security of the system. Unified code specifications facilitate collaboration and communication among team members. When team members all follow the same coding standards, it is easier to understand and maintain the code, reducing misunderstandings and conflicts caused by inconsistent coding styles.

[0028] S120, dynamically traversing all code elements of the project to be detected through a Java reflection mechanism, wherein the code elements include classes, methods, and fields; The Java reflection mechanism provides the ability to inspect classes, interfaces, fields, and methods at runtime. It allows programs to dynamically load classes, access class attributes and methods, and even create class instances at runtime. Reflection is mainly implemented through classes in the java.lang.reflect package, such as Class, Method, Field, etc. To dynamically traverse all code elements in the project to be detected, you need to perform the following steps: Get all class information of the project to be detected. This can usually be achieved by loading the classpath of the project and then traversing all jar packages or directories under the classpath. For each class file found, you can use the Class.forName(String className) method or the loadClass(Stringname) method of ClassLoader to load the class and get its Class object. Once you have the Class object of the class, you can start traversing the structure of the class. Use the Class.getDeclaredFields() method to get all the fields declared in the class (including private fields). The information of these fields is stored in the Field object, and the name, type, modifiers, and other information of the field can be obtained through the Field object. Use the Class.getDeclaredMethods() method to get all the methods declared in the class (including private methods). The information of these methods is stored in the Method object, through which you can get the method's name, parameter type, return type, modifiers and other information. Use the Class.getDeclaredConstructors() method to get all the constructors declared in the class. The information of the constructor is stored in the Constructor object. Similar to the Method object, you can get the parameter type, modifiers and other information of the constructor. If the class contains inner classes, you can use the Class.getDeclaredClasses() method to get the Class objects of these inner classes and traverse them recursively. When traversing the structure of the class, you can use the API provided by reflection to access and manipulate these code elements. For example, you can use the Method.invoke(Object obj, Object...args) method to call a class method, and use the Field.get(Object obj) or Field.set(Object obj, Object value) method to get or set the value of the field.

[0029] Optionally, dynamically traversing all code elements in the project to be detected by using a Java reflection mechanism further includes: Load the class file in the project to be detected by using the Java class loader according to the preset class path, and obtain the class object from the class file; Obtain the root package name in the project to be detected, and traverse each package starting from the root package name; In the process of traversing the package, for each class, the method list and field list of the class are obtained through the reflection method according to the class object; The method list and the field list are recorded in a log or data structure.

[0030] Use Java's class loader to load class files in the project to be detected according to the preset class path. The class path is a list of directories, JAR files, or ZIP files where Java looks for class files. The class loader is responsible for reading class files at these locations and converting them into class objects (Class objects) in the Java runtime environment. After loading the class files and obtaining the class objects, you need to determine the root package name of the project to be detected. The root package name is usually the top-level package name of the project code structure, which defines the namespace of all classes in the project. The way to obtain the root package name may vary depending on the project structure and build tool, but it can usually be determined by analyzing the project's source code or build configuration files (such as Maven's pom.xml or Gradle's build.gradle). Once you have the root package name, you can start traversing each package and the classes it contains. Java's reflection mechanism provides the Package class to represent packages, but it is not always feasible to obtain all packages directly through reflection because Java's class loading mechanism loads classes on demand. Therefore, it may be necessary to combine other techniques (such as file system traversal, class path scanning, etc.) to find all possible packages and classes. In the process of traversing the package, for each class file found, use the class loader to load it as a class object. Then, use reflection methods (such as Class.getDeclaredMethods() and Class.getDeclaredFields()) to obtain the method list and field list of the class. Finally, the obtained method list and field list are recorded in the log or stored in a data structure for subsequent analysis and processing. Recording in the log can facilitate viewing and debugging, while storing in the data structure can provide data support for further automated analysis or testing.

[0031] Through the reflection mechanism, the internal structure of the class can be obtained dynamically at runtime without statically analyzing the code at compile time. This makes code analysis more flexible and can adapt to changes in different projects and requirements. Traversing all code elements in the project to be tested, including classes, methods, fields, etc., can ensure the comprehensiveness of code review. This helps to discover potential code problems and improve code quality. The reflection mechanism can not only be used to read class information, but also to dynamically create objects, call methods, modify fields, etc. This makes dynamic code generation and modification possible, and helps to achieve a more flexible and scalable system architecture. Recording the obtained method list and field list in a log or data structure helps developers understand the internal structure and running status of the system. This is very useful when debugging and performing performance analysis on the system. Code analysis through the reflection mechanism can help developers better understand the code structure of the system. This helps to reduce the complexity of the system and improve the maintainability of the code. At the same time, the reflection mechanism can also be used to implement some automated code generation tools to further reduce the burden on developers.

[0032] Optionally, obtaining a method list and a field list of a class by a reflection method according to the class object includes: Use Java reflection to obtain all methods and all fields of the current class; For each method, construct a unique first identifier based on the name of the method, the parameter type list, the return type, and the class name of the method, associate the first identifier with the first information of the corresponding method, and construct a method list based on the first information; For each field, a unique second identifier is constructed based on the name of the field, the field type, and the class name to which the field belongs, the second identifier is associated with the second information of the corresponding field, and a field list is constructed according to the second information.

[0033] Through Java's reflection mechanism, you can use the getDeclaredMethods() method of the Class class to obtain all methods of the current class (including private methods, protected methods, default access rights methods, and public methods, but excluding methods inherited from parent classes). Similarly, you can use the getDeclaredFields() method of the Class class to obtain all fields of the current class (including private fields, protected fields, default access rights fields, and public fields, but excluding fields inherited from parent classes). For each method, you need to build an identifier that can uniquely identify the method. This identifier can be built based on the method name, parameter type list, return type, and class name of the method. The method name, parameter type list, and return type together constitute the method signature, while the class name is used to distinguish between methods with the same name in different classes. By combining this information into a string (which may also require certain formatting or encoding to ensure uniqueness), a unique first identifier can be obtained. The first information may include the method's access modifier, whether it is a static method, whether it is an abstract method, the type of exception thrown, etc. This first identifier can be used as a key and the corresponding first information can be used as a value to store in a data structure (such as a Map). By traversing the above data structure, we can collect information about all methods and build a method list. This method list can be a simple list of objects, each of which contains a unique identifier for the method and the corresponding first information. For each field, an identifier that can uniquely identify the field also needs to be built. This identifier can be built based on the name of the field, the field type, and the class name of the field. The field name and field type together constitute the identifier of the field, while the class name is used to distinguish between fields with the same name in different classes. Similarly, by combining this information into a string (which may also need to be formatted or encoded to ensure uniqueness), a unique second identifier can be obtained. The second information may include the access modifier of the field, whether it is a static field, whether it is a final field (i.e., a constant), etc. This second identifier can be used as a key and the corresponding second information can be used as a value to store in a data structure (such as a Map). By traversing the above data structure, we can collect information about all fields and build a field list. This field list can be a simple list of objects, each of which contains a unique identifier for the field and the corresponding second information.

[0034] Using the Java reflection API (application programming interface), you can get all methods and all fields of the current class. This is the basic function of the reflection mechanism, which provides basic data for subsequent processing. For each method, a unique first identifier is constructed based on the method name, parameter type list, return type, and the class name of the method. This identifier ensures that each method is unique throughout the project, avoiding duplication and confusion. For each field, a unique second identifier is constructed based on the field name, field type, and the class name of the field. Similarly, this identifier also ensures that each field is unique throughout the project. The first identifier is associated with the first information of the corresponding method, which may include the method's access modifier, annotation, exception information, etc. The second identifier is associated with the second information of the corresponding field, which may include the field's access modifier, initial value, annotation, etc. Based on the associated information, a method list and a field list are constructed respectively. These lists facilitate subsequent code analysis, processing, or generation. By constructing a unique identifier, it can be ensured that each method and field can be accurately identified and located during the subsequent code analysis process. This avoids misjudgment and omissions caused by name conflicts or similarities. Having a unique identifier and an associated list of information allows you to work with code elements more flexibly. For example, you can find and call a method based on its name and parameter types, or access and modify the value of a field based on its name and type.

[0035] S130, checking the code elements one by one according to the rule set to determine whether the code elements comply with the code specification; Each acquired code element needs to be checked one by one to determine whether it meets the requirements of the rule set. This step may involve the following aspects: Naming check: Verify whether the naming of code elements complies with the naming rules specified in the specification. For example, whether the class name starts with an uppercase letter, whether the method name uses camel case, etc.

[0036] Format check: Check whether the format of code elements conforms to the code format specified in the specification. For example, whether the indentation is consistent, whether the correct spaces and line breaks are used, etc.

[0037] Comment check: Verify whether the code elements contain necessary comments and whether the comments meet the requirements in the specification. For example, whether the comments are clear and accurate, and whether the correct comment style is used.

[0038] Coding style check: Check whether the coding style of code elements meets the requirements of the specification. For example, whether specific coding conventions are followed, whether unnecessary code redundancy is avoided, etc.

[0039] During the inspection process, the inspection results of each code element need to be recorded. These results can include whether the code element complies with the specification, the specific reasons for non-compliance with the specification, and the modification suggestions required. Recording the inspection results will help with subsequent code modification and tracking.

[0040] Figure 2 is a code explanation diagram of a method for improving code quality by using a Java reflection mechanism disclosed in an embodiment of the present application, such as Figure 2 As shown, get all classes under the specified package, if the class name does not meet the specification, output exception information, get all method names under the class, if the method name does not meet the specification, output exception information.

[0041] Figure 3 is a schematic diagram of the execution of the method for improving code quality by using the Java reflection mechanism disclosed in the embodiment of the present application, such as Figure 3 As shown, get the verification tool class, set the package path, get all the classes under the package, and start standard verification.

[0042] Optionally, checking the code elements one by one according to the rule set to determine whether the code elements comply with the code specification includes: Extracting a rule subset related to the element type of the current code element from the rule set; When the element type is a class, checking whether the naming of the current code element complies with the naming convention, whether the structure complies with the code structure specification, and whether the coding style complies with the coding style requirements according to the rule subset; When the element type is a method, checking whether the naming, parameter list, return type and method body of the current code element conform to the specification according to the rule subset; When the element type is a field, checking whether the naming, type and initial value of the current code element conform to the specification according to the rule subset; If the current code element does not comply with any rule, it is determined that the current code element does not comply with the code specification.

[0043] Before the check begins, you first need to extract the relevant rule subsets from the predefined rule set based on the type of the current code element (such as class, method, field, etc.). These rule subsets contain all the check items and corresponding requirements for the code element of that type.

[0044] When the type of the current code element is a class, the following checks are performed based on the extracted rule subset: Naming check: Verify whether the class naming complies with the naming convention, such as whether meaningful names are used, whether specific naming rules (such as camel case) are followed, etc. Structural check: Check whether the class structure complies with the code structure specifications, such as whether it contains necessary member variables, methods, constructors, etc., and whether the organizational relationship between these members and methods is reasonable; Coding style check: Verify whether the coding style of the class meets the coding style requirements, such as whether the correct indentation, spacing, line breaks and other formats are used, whether specific coding conventions are followed, etc.

[0045] When the type of the current code element is a method, the following checks are performed according to the extracted rule subset: Naming check: Verify whether the method naming complies with the naming convention, such as whether the method function is clearly expressed and whether specific naming rules are followed; Parameter list check: Check whether the parameter list of the method complies with the specification, such as whether the number, type, order, etc. of parameters are reasonable, whether it contains unnecessary parameters or lacks necessary parameters; Return type check: Verify whether the return type of the method complies with the specification, such as whether the correct type is returned, whether unnecessary generic use is avoided, etc.; Method body check: Check whether the implementation of the method body complies with the specifications, such as whether it contains necessary logical processing, whether it follows a specific coding style, etc.

[0046] When the type of the current code element is field, the following checks are performed according to the extracted rule subset: Naming check: Verify whether the field names comply with naming conventions, such as whether meaningful names are used and whether specific naming rules are followed; Type checking: Check whether the type of the field complies with the specification, such as whether the correct data type is used, whether unnecessary type conversion is avoided, etc. Initial value check: Verify whether the initial value of the field meets the specifications, such as whether a reasonable default value is set and whether unnecessary empty values ​​are avoided.

[0047] During the inspection process, if it is found that the current code element does not meet any rule (i.e., violates a requirement in the rule set), it can be determined that the code element does not meet the code specification. At this time, the corresponding error information can be recorded or an inspection report can be generated for subsequent code modification and optimization.

[0048] By extracting a subset of rules related to the current code element type from the rule set, the interference of irrelevant rules can be significantly reduced and the inspection efficiency can be improved. This avoids comparing all rules one by one during the inspection process, thus saving time and computing resources. Specific inspection contents are proposed for different types of code elements. This targeted inspection method makes the inspection process clearer and more efficient, and helps to quickly locate and identify code elements that do not meet the specifications. For the naming of classes, methods, and fields, by checking whether they comply with the naming conventions, the readability and consistency of the code can be ensured. This helps developers to understand and maintain the code more easily. For the structure of the class, by checking whether it complies with the code structure specifications, it can be ensured that the design of the class is reasonable, clear, and in line with object-oriented design principles. By checking whether the coding style of the code element meets the requirements, the consistency of the code style can be ensured, and the readability and maintainability of the code can be improved. If the current code element does not comply with any rule, it is determined that it does not comply with the code specifications. This helps to identify problems in the code in a timely manner and provide feedback to developers. Developers can make corresponding modifications and optimizations based on the feedback, thereby continuously improving the quality of the code.

[0049] S140: When the code element does not comply with the code specification, prompt that an abnormality occurs in the code element.

[0050] The content of abnormal prompts usually includes the following aspects: Problem description: briefly describe the problem of the code element not meeting the specification. For example, "the class name does not meet the naming convention", "the method lacks the necessary comments", etc.

[0051] Location information: Provides the specific location where the problem occurred, such as file name, line number, and column number. This helps developers quickly locate the problem.

[0052] Repair suggestions: Provide specific repair suggestions based on the nature of the problem, such as "It is recommended to modify the class name to comply with the naming convention", "Please add necessary comments to the method", etc.

[0053] Rule references: Reference relevant coding standards or rule sets so that developers understand the context and rationale for the problem.

[0054] Optionally, the prompting that the code element is abnormal includes: Generate an exception report based on the code element that does not conform to the specification, wherein the exception report includes the element type, the class name, the location in the code, the non-conforming code fragment and the violated rules; According to the exception report, the code elements that do not meet the specifications are pointed out in the code editing interface by highlighting, underlining or popping up a prompt box, and modification suggestions or repair options are provided.

[0055] When a code element (such as a class, method, field, etc.) does not comply with the code specification, the system will first identify the type of the element (such as a class, method, etc.) and the class name. At the same time, the system will record the specific location of the element in the code, including the file name, line number, and column number, so that developers can quickly locate the problem. The system will extract and display the code snippet that does not comply with the specification. This helps developers intuitively understand the problem and quickly identify the part that needs to be modified. The system will reference the relevant code specification or rule set to clearly indicate the specific rule that the code element violates. This helps developers understand the background and basis of the problem so that they can better fix it. The above information will be integrated into an exception report. This report is usually presented in the form of text or table, which is convenient for developers to review and record. In the code editing interface, code elements that do not comply with the specification will be highlighted with a specific color or background. This visual emphasis helps developers quickly identify the problem. In addition to highlighting, the system can also use underscores to mark code elements that do not comply with the specification. This marking method also helps developers quickly locate the problem. When the developer moves the cursor to a code element that does not comply with the specification, the system can pop up a prompt box. This prompt box will display some or all of the information in the exception report, including the element type, class name, location information, non-compliant code snippets, and violated rules. This helps developers get complete exception information without leaving the code editing interface. In the exception report or pop-up prompt box, the system will provide specific modification suggestions. These suggestions are usually based on violated rules and best practices, and are designed to help developers quickly fix problems. In addition to modification suggestions, the system can also provide a one-click repair option. When the developer selects this option, the system will automatically modify the non-compliant code elements to make them comply with the code specifications. This automated repair method can greatly improve the efficiency of repairs and reduce the workload of manual modifications.

[0056] By generating an exception report, you can accurately identify code elements that do not conform to the specification, including their type, class name, location in the code, and specific rules violated. This provides developers with a detailed description of the problem, helping them to accurately understand the problem. The non-conforming code snippets and modification suggestions or repair options included in the exception report provide developers with clear repair directions. This helps developers quickly locate and fix problems, thereby improving the overall quality of the code. In the code editing interface, highlighting, underlining, or popping up a prompt box points to code elements that do not conform to the specification, allowing developers to immediately notice the problem. This intuitive prompt method reduces the time developers spend looking for problems and improves repair efficiency.

[0057] Optionally, the method further includes: Setting a code quality threshold, and scoring the code quality of the project to be detected according to the code quality threshold; Generate a code quality report based on the score, wherein the code quality report includes the number and type distribution of code elements that do not conform to the specification, and historical change trends; Generate code quality improvement suggestions based on the code quality report, where the code quality improvement suggestions include the highest priority code elements that need to be corrected.

[0058] The purpose of setting a code quality threshold is to quantify the code quality and set an acceptable minimum quality standard for the project. This helps ensure that the code quality of the project remains above a certain level and avoids potential problems caused by low code quality. Different code quality thresholds can be set according to the actual situation of the project and the needs of the team. These thresholds can be set based on factors such as the number of code elements that do not meet the specifications, type distribution, and historical change trends. For example, a threshold can be set so that when the number of code elements that do not meet the specifications exceeds a certain proportion, the code quality is considered to be substandard. The code quality report is a comprehensive document that contains detailed information about the code quality. This information includes the number and type distribution of code elements that do not meet the specifications, historical change trends, etc. With this information, developers can fully understand the code quality status of the project and find potential problems and improvement points. Code quality reports can be generated by automated tools, which scan and analyze the code according to preset rules and thresholds, and then generate detailed reports. Reports are usually presented in the form of charts, tables, etc., making the information more intuitive and easy to understand. Generating code quality improvement suggestions is to help developers identify and solve quality problems in the code and further improve code quality. These suggestions are usually based on the information and analysis results in the code quality report. Code quality improvement suggestions include the highest priority code elements that need to be fixed. These elements are usually the parts of the code that have the greatest impact on code quality and are most likely to cause problems. By fixing these elements first, the overall quality of the code can be significantly improved. Code quality improvement suggestions can be generated by automated tools or manual analysis. Automated tools can automatically identify and recommend code elements that need to be fixed based on preset rules and algorithms. Manual analysis requires developers to make specific improvement suggestions based on the information in the code quality report and their own experience and judgment.

[0059] By setting code quality thresholds for the projects to be tested, it is possible to clearly distinguish between qualified and unqualified standards for code quality. This helps the project management team to quantitatively manage code quality and ensure that the project code meets the established quality standards. Scoring the code according to the code quality threshold can more objectively reflect the overall quality level of the code. The scoring system not only considers whether the code complies with the specifications, but also may consider multiple dimensions such as the complexity, readability, and maintainability of the code, thereby providing a more comprehensive code quality assessment. Generating a code quality report that includes the number of code elements that do not comply with the specifications, the type distribution, and the historical change trend can help developers and project management teams gain a deeper understanding of the current status and development trends of code quality. By comparing reports at different time points, the changing patterns and potential problems of code quality can be discovered, providing a basis for subsequent improvements. The type distribution information in the report can help developers identify which types of code elements are more likely to have problems, so as to strengthen the training and implementation of relevant specifications in a targeted manner. The historical change trend helps to discover the patterns and trends of code quality changes and provide support for project management and decision-making. Generating the highest priority code element recommendations that need to be corrected based on the code quality report can help developers and project management teams focus on solving the most critical problems. These suggestions may include specific repair steps, modification suggestions, or optimization directions, providing developers with clear directions for improvement. By setting priorities, developers can be ensured to deal with the most urgent issues that have the greatest impact on code quality first. This helps to maximize the improvement of code quality with limited resources.

[0060] Figure 4 is a test code snippet disclosed in the embodiment of this application, such as Figure 4 As shown, the method of the class in the test code snippet does not satisfy the pre-specified method name regular expression. The specification is that the first letter needs to be a lowercase letter, so in theory it is necessary to output the anomaly detection report information.

[0061] Figure 5 : is a schematic diagram of the test results obtained after testing the test code snippet using the method for improving code quality using the Java reflection mechanism disclosed in the embodiment of the present application, such as Figure 5 As shown, the desired information is output normally and the exception is successfully detected. The program developer can modify it according to the exception information.

[0062] This embodiment also discloses a system for improving code quality by using Java reflection mechanism. Figure 6 is a schematic diagram of a module of a system for improving code quality by using a Java reflection mechanism disclosed in an embodiment of the present application, such as Figure 6 As shown, the system includes a rule module 601, a traversal module 602, a check module 603 and a prompt module 604, wherein: A rule module 601 is configured to set the code specifications in the project to be detected and convert the code specifications into a rule set, wherein the code specifications include naming conventions, code structure and coding style; A traversal module 602 is configured to dynamically traverse all code elements in the project to be detected through a Java reflection mechanism, wherein the code elements include classes, methods and fields; A checking module 603, configured to check the code elements one by one according to the rule set to determine whether the code elements comply with the code specification; The prompt module 604 is configured to prompt that an exception occurs in the code element when the code element does not comply with the code specification.

[0063] Optionally, the rule module 601 is configured to: Determine a regular expression according to the code specification, and determine whether there is a preset pattern in the code specification, and the preset pattern cannot be directly matched by the regular expression; When there is a preset mode in the code specification, determining the verification logic according to the preset mode; The regular expression and the validation logic are associated with corresponding check items to form a definition file, and a rule set is configured according to the definition file.

[0064] Optionally, the traversal module 602 is configured to: Load the class file in the project to be detected by using the Java class loader according to the preset class path, and obtain the class object from the class file; Obtain the root package name in the project to be detected, and traverse each package starting from the root package name; In the process of traversing the package, for each class, the method list and field list of the class are obtained through the reflection method according to the class object; The method list and the field list are recorded in a log or data structure.

[0065] Optionally, the traversal module 602 is configured to: Use Java reflection to obtain all methods and all fields of the current class; For each method, construct a unique first identifier based on the name of the method, the parameter type list, the return type, and the class name of the method, associate the first identifier with the first information of the corresponding method, and construct a method list based on the first information; For each field, a unique second identifier is constructed based on the name of the field, the field type, and the class name to which the field belongs, the second identifier is associated with the second information of the corresponding field, and a field list is constructed according to the second information.

[0066] Optionally, the checking module 603 is configured to: Extracting a rule subset related to the element type of the current code element from the rule set; When the element type is a class, checking whether the naming of the current code element complies with the naming convention, whether the structure complies with the code structure specification, and whether the coding style complies with the coding style requirements according to the rule subset; When the element type is a method, checking whether the naming, parameter list, return type and method body of the current code element conform to the specification according to the rule subset; When the element type is a field, checking whether the naming, type and initial value of the current code element conform to the specification according to the rule subset; If the current code element does not comply with any rule, it is determined that the current code element does not comply with the code specification.

[0067] Optionally, the prompt module 604 is configured to: Generate an exception report based on the code element that does not conform to the specification, wherein the exception report includes the element type, the class name, the location in the code, the non-conforming code fragment and the violated rules; According to the exception report, the code elements that do not meet the specifications are pointed out in the code editing interface by highlighting, underlining or popping up a prompt box, and modification suggestions or repair options are provided.

[0068] Optionally, the system further comprises a quality module, wherein the quality module is configured to: Setting a code quality threshold, and scoring the code quality of the project to be detected according to the code quality threshold; Generate a code quality report based on the score, wherein the code quality report includes the number and type distribution of code elements that do not conform to the specification, and historical change trends; Generate code quality improvement suggestions based on the code quality report, where the code quality improvement suggestions include the highest priority code elements that need to be corrected.

[0069] It should be noted that: when the device provided in the above embodiment realizes its function, only the division of the above functional modules is used as an example. In actual application, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the device and method embodiments provided in the above embodiment belong to the same concept, and the specific implementation process is detailed in the method embodiment, which will not be repeated here.

[0070] This embodiment also discloses an electronic device, referring to Figure 7The electronic device may include: at least one processor 701 , at least one communication bus 702 , a user interface 703 , a network interface 704 , and at least one memory 705 .

[0071] The communication bus 702 is used to realize the connection and communication between these components.

[0072] The user interface 703 may include a display screen (Display) and a camera (Camera). Optionally, the user interface 703 may also include a standard wired interface and a wireless interface.

[0073] The network interface 704 may optionally include a standard wired interface or a wireless interface (such as a WI-FI interface).

[0074] Among them, the processor 701 may include one or more processing cores. The processor 701 uses various interfaces and lines to connect various parts in the entire server, and executes various functions of the server and processes data by running or executing instructions, programs, code sets or instruction sets stored in the memory 705, and calling data stored in the memory 705. Optionally, the processor 701 can be implemented in at least one hardware form of digital signal processing (Digital Signal Processing, DSP), field programmable gate array (Field-Programmable Gate Array, FPGA), and programmable logic array (Programmable Logic Array, PLA). The processor 701 can integrate one or a combination of a central processing unit (Central Processing Unit, CPU), a graphics processing unit (Graphics Processing Unit, GPU) and a modem. Among them, the CPU mainly processes the operating system, user interface and application programs; the GPU is responsible for rendering and drawing the content to be displayed on the display screen; the modem is used to process wireless communications. It can be understood that the above-mentioned modem may not be integrated into the processor 701, and it can be implemented separately through a chip.

[0075] Among them, the memory 705 may include a random access memory (Random Access Memory, RAM) and may also include a read-only memory (Read-Only Memory). Optionally, the memory 705 includes a non-transitory computer-readable storage medium. The memory 705 can be used to store instructions, programs, codes, code sets or instruction sets. The memory 705 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playback function, an image playback function, etc.), instructions for implementing the above-mentioned various method embodiments, etc.; the data storage area may store data involved in the above-mentioned various method embodiments, etc. The memory 705 may also be optionally at least one storage device located away from the aforementioned processor 701. As Figure 7 As shown, the memory 705 as a computer storage medium may include an operating system, a network communication module, a user interface module, and an application program of a method for improving code quality using a Java reflection mechanism.

[0076] exist Figure 7 In the electronic device shown, the user interface 703 is mainly used to provide an input interface for the user and obtain data input by the user; and the processor 701 can be used to call an application stored in the memory 705 for a method of improving code quality using a Java reflection mechanism. When executed by one or more processors 701, the electronic device executes one or more methods in the above-mentioned embodiments.

[0077] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all described as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the order of the actions described, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required for the present application.

[0078] In the above embodiments, 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.

[0079] In the several embodiments provided in this application, it should be understood that the disclosed devices can be implemented in other ways. For example, the device embodiments described above are only schematic, such as the division of units, which is only a logical function division. There may be other division methods in actual implementation, such as 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 service interfaces, and the indirect coupling or communication connection of devices or units can be electrical or other forms.

[0080] 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 network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0081] In addition, each functional unit in each embodiment of the present application 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-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0082] 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 memory. Based on this understanding, the technical solution of the present application, 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, which is stored in a memory 705 and includes several instructions for a computer device (which can be a personal computer, server or network device, etc.) to execute all or part of the steps of the various embodiments of the present application. The aforementioned memory 705 includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a magnetic disk or an optical disk.

[0083] The above is only an exemplary embodiment of the present disclosure and cannot be used to limit the scope of the present disclosure. That is, any equivalent changes and modifications made according to the teachings of the present disclosure are still within the scope of the present disclosure. After considering the disclosure of the specification, those skilled in the art will easily think of other embodiments of the present disclosure. This application is intended to cover any modification, use or adaptation of the present disclosure, which follows the general principles of the present disclosure and includes common knowledge or customary technical means in the technical field that are not recorded in the present disclosure. The description and examples are only regarded as exemplary, and the scope and spirit of the present disclosure are defined by the claims.

Claims

1. A method for improving code quality by using Java reflection mechanism, characterized in that: Applied to a code detection platform, the method includes: Set code specifications in the project to be detected and convert the code specifications into a rule set, wherein the code specifications include naming conventions, code structure and coding style; Dynamically traverse all code elements in the project to be detected through a Java reflection mechanism, wherein the code elements include classes, methods, and fields; Checking the code elements one by one according to the rule set to determine whether the code elements comply with the code specification; When the code element does not comply with the code specification, it is prompted that an exception occurs in the code element.

2. The method for improving code quality by using Java reflection mechanism according to claim 1, characterized in that: The step of setting the code specification in the project to be detected and converting the code specification into a rule set includes: Determine a regular expression according to the code specification, and determine whether there is a preset pattern in the code specification, and the preset pattern cannot be directly matched by the regular expression; When there is a preset mode in the code specification, determining the verification logic according to the preset mode; The regular expression and the validation logic are associated with corresponding check items to form a definition file, and a rule set is configured according to the definition file.

3. The method for improving code quality by using Java reflection mechanism according to claim 1, characterized in that: The dynamically traversing all code elements of the project to be detected by using the Java reflection mechanism also includes: Load the class file in the project to be detected by using the Java class loader according to the preset class path, and obtain the class object from the class file; Obtain the root package name in the project to be detected, and traverse each package starting from the root package name; In the process of traversing the package, for each class, the method list and field list of the class are obtained through the reflection method according to the class object; The method list and the field list are recorded in a log or data structure.

4. The method for improving code quality by using Java reflection mechanism according to claim 3, characterized in that: The method list and field list of a class are obtained by reflection method according to the class object, including: Use Java reflection to obtain all methods and all fields of the current class; For each method, construct a unique first identifier based on the name of the method, the parameter type list, the return type, and the class name of the method, associate the first identifier with the first information of the corresponding method, and construct a method list based on the first information; For each field, a unique second identifier is constructed based on the name of the field, the field type, and the class name to which the field belongs, the second identifier is associated with the second information of the corresponding field, and a field list is constructed according to the second information.

5. The method for improving code quality by using Java reflection mechanism according to claim 1, characterized in that: The checking the code elements one by one according to the rule set to determine whether the code elements comply with the code specification includes: Extracting a rule subset related to the element type of the current code element from the rule set; When the element type is a class, checking whether the naming of the current code element complies with the naming convention, whether the structure complies with the code structure specification, and whether the coding style complies with the coding style requirements according to the rule subset; When the element type is a method, checking whether the naming, parameter list, return type and method body of the current code element conform to the specification according to the rule subset; When the element type is a field, checking whether the naming, type and initial value of the current code element conform to the specification according to the rule subset; If the current code element does not comply with any rule, it is determined that the current code element does not comply with the code specification.

6. The method for improving code quality by using Java reflection mechanism according to claim 1, characterized in that: The prompt that the code element is abnormal includes: Generate an exception report based on the code element that does not conform to the specification, wherein the exception report includes the element type, the class name, the location in the code, the non-conforming code fragment and the violated rules; According to the exception report, the code elements that do not meet the specifications are pointed out in the code editing interface by highlighting, underlining or popping up a prompt box, and modification suggestions or repair options are provided.

7. The method for improving code quality by using Java reflection mechanism according to claim 1, characterized in that: The method further comprises: Setting a code quality threshold, and scoring the code quality of the project to be detected according to the code quality threshold; Generate a code quality report based on the score, wherein the code quality report includes the number and type distribution of code elements that do not conform to the specification, and historical change trends; A code quality improvement suggestion is generated according to the code quality report, wherein the code quality improvement suggestion includes a code element with the highest priority that needs to be corrected.

8. A system for improving code quality using Java reflection mechanism, characterized in that: It includes rule module, traversal module, inspection module and prompt module, among which: A rule module is configured to set code specifications in the project to be detected and convert the code specifications into a rule set, wherein the code specifications include naming conventions, code structure and coding style; A traversal module, configured to dynamically traverse all code elements in the project to be detected through a Java reflection mechanism, wherein the code elements include classes, methods and fields; A checking module, configured to check the code elements one by one according to the rule set to determine whether the code elements comply with the code specification; The prompt module is configured to prompt that an exception occurs in the code element when the code element does not comply with the code specification.

9. An electronic device, characterized in that: It includes a processor, a memory, a user interface and a network interface, the memory is used to store instructions, the user interface and the network interface are both used to communicate with other devices, and the processor is used to execute the instructions stored in the memory so that the electronic device executes the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions, and when the instructions are executed, the method according to any one of claims 1 to 7 is executed.

Images