[Summary] Enhance code style warnings in server

[msgui]

SubTask

PS: One PR for multiple modules is fine, but if the total code exceeds 4000 lines, split it into multiple PRs.

• Adhere to the code conventions outlined in HugeGraph-Code-Style-Guide (please refine the hg-style.xml specification @returnToInnocence) chore: refine the hg-style.xml specification #2457
  • Add the option 'BLANK_LINES_AFTER_CLASS_HEADER'
  • Add the option 'KEEP_BLANK_LINES'
  • ....
• Correct the copyright format.
  • fix(server): unify the license headers #2438
  • chore: improve license header checker confs and pre-check header when validating #2445
• Format the server module
  • hugegraph-api & cassandra & palo & postgresql & rocksdb & scylladb & test & hbase & mysql (wip fix: format and clean code in modules #2439)
  • hugegraph-core fix: format and clean code in core module #2440
  • hugegraph-dist & example fix: format and clean code in dist and example modules #2441
  • remove extra blank lines fix(server): remove extra blank lines #2459
• clean up the code. fix(server): clean up the code #2456
• Doc hugegraph.feishu.cn/wiki/NzaxwWIRHi5mJGkXkR0cHx6mnbg@returnToInnocence
  • Provide doc on how to retain/install multiple versions of IntelliJ IDE
  • Unified IDE Rules Setup Tutorial

Expected & Actual behavior (期望与实际表现)

TODO

• IDEA formatting plugin currently lacks support for adding a blank line after enum declarations.
• Use spotless to format code

[dosubot]

🤖

I'm sorry, but I'm unable to view the images you've attached. However, I can provide some general advice on why the server module might be triggering warnings when using check-style.

The server module might trigger warnings due to several reasons:

1. Line Length: The recommended line length is less than or equal to 100 characters. If the code in the server module exceeds this limit, it will trigger a warning.

2. Alignment and Indentation: The code style guide suggests that for strings and function parameters, alignment has a higher priority than indentation. If the code in the server module doesn't follow this rule, it will trigger a warning.

3. Empty Lines: The code style guide specifies certain situations where an empty line should be added. If the code in the server module doesn't follow these rules, it will trigger a warning.

4. Variable and Method Naming: The code style guide suggests using camel case for variable and method naming, and method names should not have get, set, is prefixes. If the code in the server module doesn't follow these rules, it will trigger a warning.

5. Error Checking: The code style guide suggests using E.checkArgument() and E.checkState() for error checking instead of if + throw. If the code in the server module doesn't follow this rule, it will trigger a warning.

6. Exception Handling: The code style guide suggests handling exceptions at the top-level call or external API call. If the code in the server module doesn't follow this rule, it will trigger a warning.

7. Logging: The code style guide suggests using {} for placeholders in log messages instead of string concatenation. If the code in the server module doesn't follow this rule, it will trigger a warning.

8. String Concatenation: The code style guide suggests using String.format() for string concatenation. If the code in the server module doesn't follow this rule, it will trigger a warning.

Please check the server module code against these rules to identify the specific cause of the warnings. You can refer to the Hugegraph Code Style Guide for more details.

Without the specific warnings or the exact lines of code that are causing these warnings, it's difficult to provide a more precise answer. If you could provide more details about the warnings, such as the warning messages or the lines of code that are causing these warnings, I would be able to provide a more accurate response.

Sources

• Hugegraph Code Style Guide
• style/checkstyle.xml

---

This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.

[VGalaxies]

@msgui consider introducing the specific steps for formatting, cleaning, and correcting in the relevant PRs to help us in PR validation :)

[msgui]

consider introducing the specific steps for formatting, cleaning, and correcting in the relevant PRs to help us in PR validation :)

1. Configure IDEA based on the Config Style full version - fs.

2. Review whether hugegraph-style.xml aligns with the specifications outlined in the HugeGraph Code Style Guide.

3. Import the latest license header (found at the end of the HugeGraph Code Style Guide) into IDEA and utilize the "Update Copyright" feature to keep the license header up-to-date.

4. Utilize IDEA plugins such as Reformat and Clean Code for code formatting.

[returnToInnocence]

Adhere to the code conventions outlined in HugeGraph-Code-Style-Guide (please refine the hg-style.xml specification @returnToInnocence)#2457

[returnToInnocence]

Suddenly a new idea, perhaps as a future thing to do, is to try to migrate the entire contents of the entire hg-style.xml file to.editorconfig

This is because the.editorconfig file has some other advantages that hg-style.xml does not have when I was looking at the documentation for this, such as:

• The.editorconfig file can also define coding conventions that cannot be defined by hg-style.xml, such as code style, formatting, and naming, which can help improve code consistency and readability.
• The.editorconfig file does not require the user to make any additional configuration, such as importing code style. If this file exists in the project, it will be automatically invoked by default, and code sytle will be overwritten

Therefore, I wonder if we should further try to gather the configuration of a function as much as possible in the future, instead of spreading it into multiple Settings, and reduce the user's perception of format as little as possible at one time

[VGalaxies]

Suddenly a new idea, perhaps as a future thing to do, is to try to migrate the entire contents of the entire hg-style.xml file to.editorconfig

This is because the.editorconfig file has some other advantages that hg-style.xml does not have when I was looking at the documentation for this, such as:

• The.editorconfig file can also define coding conventions that cannot be defined by hg-style.xml, such as code style, formatting, and naming, which can help improve code consistency and readability.
• The.editorconfig file does not require the user to make any additional configuration, such as importing code style. If this file exists in the project, it will be automatically invoked by default, and code sytle will be overwritten

Therefore, I wonder if we should further try to gather the configuration of a function as much as possible in the future, instead of spreading it into multiple Settings, and reduce the user's perception of format as little as possible at one time

Indeed, I found that #2457 uses both hugegraph-style.xml and .editorconfig to control code style. If the control scope of the editorconfig file is broader than the idea code style XML, it might be worth considering consolidating them into .editorconfig.

In the context of IntelliJ IDEA, perhaps this is feasible, see https://www.jetbrains.com/help/idea/editorconfig.html

Perhaps it's possible to export the current hugegraph-style.xml to .editorconfig format and merge it with the existing .editorconfig to see if the previously defined styles are compromised...

[returnToInnocence]

Suddenly a new idea, perhaps as a future thing to do, is to try to migrate the entire contents of the entire hg-style.xml file to.editorconfig
This is because the.editorconfig file has some other advantages that hg-style.xml does not have when I was looking at the documentation for this, such as:

• The.editorconfig file can also define coding conventions that cannot be defined by hg-style.xml, such as code style, formatting, and naming, which can help improve code consistency and readability.
• The.editorconfig file does not require the user to make any additional configuration, such as importing code style. If this file exists in the project, it will be automatically invoked by default, and code sytle will be overwritten

Therefore, I wonder if we should further try to gather the configuration of a function as much as possible in the future, instead of spreading it into multiple Settings, and reduce the user's perception of format as little as possible at one time

Indeed, I found that #2457 uses both hugegraph-style.xml and .editorconfig to control code style. If the control scope of the editorconfig file is broader than the idea code style XML, it might be worth considering consolidating them into .editorconfig.

In the context of IntelliJ IDEA, perhaps this is feasible, see https://www.jetbrains.com/help/idea/editorconfig.html

Perhaps it's possible to export the current hugegraph-style.xml to .editorconfig format and merge it with the existing .editorconfig to see if the previously defined styles are compromised...

get it! I will try to export it this afternoon to see how it works!

[returnToInnocence]

• Provide doc on how to retain/install multiple versions of IntelliJ IDE @returnToInnocence
• Unified IDE Rules Setup Tutorial @returnToInnocence IDE Rules Setup Tutorial (wip)

Since the above two tasks are logically coherent, I merged them into one @msgui
https://hugegraph.feishu.cn/wiki/NzaxwWIRHi5mJGkXkR0cHx6mnbg