[Pull request] Code specification

[unitwk]

Why do you need this?

The code of open source projects usually exists for several years or even more than ten years. Due to the different habits of each developer, the combined code style is also different, so we need to have certain constraints to make the code live in a long-term and healthy manner.

When is this not needed?

If your Pull Request affects code within 40 lines, then you don't need to bother, **no need to format the plugin according to the code, just program it in your own style.

But variable names must be in camel case.

Naming conventions

TypeScript/JavaScript code variable names must be in camel case. Such as: user instanceUuid requestData

All http request parameters must be separated by underscores, with some exceptions that already exist. Such as user_id instance_uuid

Code style

Using Prettier Formatting Plugin

For development, please use VSCode for development, and must install the Prettier code formatting tool.

In the project root directory, there are already defined .prettierrc.json formatting standard files for constraints, and VSCode will automatically unify the code style.

If it doesn't work after installation, you may also need the Use...Format Document button in the right-click menu to select Prettier as the default formatting tool.

Other options

If you think it is very complicated, then please do not format any unmodified code. For example, if you modify 20 lines of code, but accidentally format 200 lines of code automatically, such PR will not be accepted.

Git Commit Information Scheme

This regulation is not mandatory, only recommended

• feat: indicates a commit to add a new feature
• fix: Indicates a commit to fix a bug
• build: Indicates that the commit modifies the build system or external dependencies
• ci: Indicates that the commit modifies a continuous build, continuous deployment configuration or script
• docs: Indicates that the commit modifies the documentation
• perf: Indicates that the commit was optimized for performance
• refactor: indicates that the commit was refactored
• style: Indicates that the submission has modified the code format problem
• test: Indicates that the commit adds or modifies the test case
• revert: roll back to the previous version
• chore: changes to the build process or auxiliary tools
• res: Indicates art resources, usually suitable for mobile terminals (our company's custom classification)

Avoid submitting Package.json files

Around the version of Node 16, the package-lock.json file of the current version will be automatically upgraded and updated, and there will probably be nearly hundreds of lines of JSON code changed. Please reject or restore the code when submitting the code. Revise.

Please do not commit any changes to the package.json package-lock.json files unless you have installed/upgraded new dependencies.