Add GDScript warnings to detect code style issues not fixable by a code formatter

[Vitorsilveira31]

Describe the project you are working on

I am working on a project using the Godot game engine. Our team is developing a 2D platformer game, and we are using GDScript as our primary scripting language.

Describe the problem or limitation you are having in your project

We have encountered issues with code consistency and quality in our project. We notice that there are inconsistencies in coding styles, such as varying spacing conventions and inconsistent typing practices. These inconsistencies make it challenging to maintain and review code, leading to potential bugs and decreased overall code quality.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

I propose the creation of a more customizable linter for Godot. This linter would allow users to define customizable rules in a configuration file. By enforcing these rules, developers can ensure consistent coding styles, improve typing practices, and maintain high code quality across the project. This enhancement would provide a way to identify and fix code inconsistencies early in the development process.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

The customizable linter would be integrated into the Godot editor, accessible through the project settings. Users could define rules in a configuration file using a simple syntax. For example, rules could specify spacing conventions, typing requirements, and naming conventions. The linter would analyze the code based on these rules and provide feedback or warnings directly within the editor interface.

If this enhancement will not be used often, can it be worked around with a few lines of script?

While some aspects of code consistency and quality can be enforced with manual checks or scripts, a dedicated linter provides a more robust and automated solution. The customizable nature of the proposed linter allows teams to tailor it to their specific needs, providing a more efficient and effective way to maintain code quality.

Is there a reason why this should be core and not an add-on in the asset library?

Given the importance of code quality and consistency in game development, a customizable linter would be a valuable addition to the core functionality of the Godot engine. By integrating it into the core, all Godot users would have access to this essential tool, promoting best practices and improving overall code quality across the community.

[dalexeev]

Consolidating in #3630.

Note that there is a difference between a formatter and a linter.

[Vitorsilveira31]

Thanks for the proposal! Consolidating in #3630.

@Calinou While the existing proposal #3630 mentions the integration of the godot-gdscript-toolkit library, it’s worth noting that this library already provides the feature I’m proposing, including customizable linting rules. However, this aspect is not explicitly specified in the proposal.

[Calinou]

Note that there is a difference between a formatter and a linter.

I know, but #3630 is pretty much addressing the same use case. A formatter can be used on CI to check whether the files are formatted correctly too. You can do so by diffing each file with a formatted copy of the file and checking if there are any differences. If there are, then the file has invalid formatting and CI should fail. (Godot could also offer a built-in CLI argument for this once the formatter is implemented.)

For local usage, a "Format on Save" editor setting addresses the same use case by not having incorrect formatting be saved in the first place (unless the script has errors). If you look at other code editors, most of them will not point out linting warnings anymore and will have the formatter deal with any issues automatically. This avoids "warning fatigue" where warnings that point out logical issues with the code may be ignored due to the user being so used to formatting-related warnings.

[dalexeev]

A linter can potentially detect problems that cannot be automatically corrected by a formatter. For example, gdlint detects the following problems:

• naming (safe auto-renaming is not always possible due to dynamic typing)
• class-definitions-order (rearranging class members may change the logic in some cases)
• comparison-with-itself
• duplicated-load
• expression-not-assigned
• function-arguments-number
• max-file-lines
• max-public-methods
• max-returns
• private-method-call
• unused-argument

Also this proposal requests customizability, while the formatter will probably have little customization, judging by gdformat and godotengine/godot#76211.