pmd
[core] add IDE agnostic configuration with `editorconfig.org`
copy of: https://github.com/checkstyle/checkstyle/issues/16543
Addressing the comment and issue of people use a lot of editors and very different versions, which is a valid concern—one good approach to handling this is using EditorConfig.
EditorConfig helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs.
Applying a strictly enforced style can be challenging without a universal solution. .editorconfig provides a way to configure the editor out of the box, making it easier to maintain consistency. The project supports many different editors, including IntelliJ, Eclipse, and VS Code. On IntelliJ, for example, it works by default, following the convention over configuration principle.
Many projects face similar issues, so it makes sense to adopt a widely used and well-supported solution as well.
Examples of projects using .editorconfig:
Relevant discussion:
This is the config representing the rules enforced by checkstyle:
[*]
charset = utf-8
end_of_line = lf
ij_continuation_indent_size = 4
indent_size = 4
indent_style = space
insert_final_newline = true
max_line_length = 100
[*.xml]
indent_size = 2
[pom.xml]
max_line_length = 140
[*.java]
ij_java_class_count_to_use_import_on_demand = 999
ij_java_else_on_new_line = true
ij_java_imports_layout = $*, |, java.**, |, javax.**, |, org.**, |, net.**, |, com.**, |, *
ij_java_names_count_to_use_import_on_demand = 999
[**xdocs-examples**.java]
ij_continuation_indent_size = 2
indent_size = 2
https://editorconfig.org/#pre-installed
Thanks for the suggestion. I think, it makes sense to add this config. But we need to mention it in the documentation, as not all IDEs/Editors use it by default. Some (like VS Code) need a plugin. So the relevant documentation needs to be updated:
- https://docs.pmd-code.org/latest/pmd_devdocs_building_intellij.html
- https://docs.pmd-code.org/latest/pmd_devdocs_building_eclipse.html
- https://docs.pmd-code.org/latest/pmd_devdocs_building_vscode.html
- https://docs.pmd-code.org/latest/pmd_devdocs_building_netbeans.html
Also, if we have this config, then I assume, we don't need e.g. the IntelliJ Specific config anymore? -> https://docs.pmd-code.org/latest/pmd_devdocs_building_intellij.html#formatter-and-inspection-configuration / https://github.com/pmd/build-tools/tree/main/intellij-idea
Also, if we have this config, then I assume, we don't need e.g. the IntelliJ Specific config anymore? -> https://docs.pmd-code.org/latest/pmd_devdocs_building_intellij.html#formatter-and-inspection-configuration / https://github.com/pmd/build-tools/tree/main/intellij-idea
Yes I think so too, but @romani has different opinion. We will find out after migration, if we still need the file for manual config. @Anmol202005
ATM its configuration over convention, but actually we want the opposite approach convention over configuration.
The setting-up-checkstyle file is needed, as it will evolve into the new .editorconfig - as the keys are 1o1 the same, like discussed in: https://github.com/checkstyle/checkstyle/pull/16349#issuecomment-2817147325
What about Spotless? How is it related (or not) to editorconfig? Can you please explain how all of those fit together and how you think we should proceed with migration to a new set of code quality plugins? Can we remove checkstyle? Are there any things that we use in checkstyle and that are not supported by spotless? How do we keep the spotless formatter synced with IDE configs? And how is a developer supposed to use these plugins? I wouldn't want the default behavior of mvn verify to change the source code. Maybe we need a maven profile or something.
I think we should answer those questions and finish this discussion before we merge or even review your PRs @Pankraz76. Your PRs #5846 #5845 #5636 and #5776 are huge and overlap, which make them difficult to review. The main problem is however that you haven't explained anywhere, in detail, what you're trying to do or how you want to get there. You should do that before you open PRs, especially if they are numerous and large.
Please take your time to write your case here; in the meantime I will close your PRs.
ah nice, thanks yes.
The topic does not change. Only the somehow, as constantly evolving, irrelevant impl. details. I have overcome myself, thanks to the learnings of maven and quarkus.
As we already agreed upon, fixing things once and for everybody, we dont need this plugin anymore as spotless is the successor, automating this burden.
.editorconfig is very limited.
Long story short, in order not to reinvent the wheel, we should leverage the convention over configuration principle and follow big bother maven, at least for ideation/conception.
You need to check if its worth to fix the eclipse config or be smart like maven let palantir to the job.
https://github.com/apache/maven-parent/blob/f4ab7c2eb04865071186c57a263243c72b6e8d52/pom.xml#L1219
Starting with the simple integration of this plugin, on trivial topic meaning imports, then build up from there, as everything is then possible.
Yes its impossible to review this of course, as we have countless flaws, which is the natural outcome, when not having auto correction like this. Nobody can to this kind of job. Except for one.
Once we have implemented, we do not need checkstyle anymore, as its 1 LOC activating ether eclipse custom config or google or palantir config, this is some detail the community needs to decide. Its not important to me, assuming nor for others, we only care about convention in general, not in detail, naturally evolving to auto fix.
When having ability to control, code becomes fluid.
One of you guys the will then just add 1 LOC activating the change.
Then you check (locally) the pattern, as we can not check 1.200 header files in detail as discovered in:
- https://github.com/pmd/pmd/issues/5850
- https://github.com/pmd/pmd/pull/5845
As these changes are ALL about pattern they are "easy" to review as all the same. Humans maybe error prone, but master of disaster, tend to pattern and natural symmetry considering PI 3.1415926535.....
You simply have to trust the tool it will execute itself and validate just like the maven build will fix itself.
Yes its impossible to review this of course, as we have countless flaws, which is the natural outcome, when not having auto correction like this. Nobody can to this kind of job. Except for one.
the good thing is they are done one time only, then they are fixed by design/devinition.
new feat incoming, as this would address a lot of flaws, ideally all, as spotless will check and apply all the time.
- https://github.com/diffplug/spotless/pull/2517
Its all related and spot the solution to all:
- https://github.com/pmd/pmd/issues/5848
- https://github.com/pmd/pmd/issues/5850
- https://github.com/pmd/pmd/pull/5845
- https://github.com/pmd/pmd/pull/5776
- https://github.com/pmd/pmd/pull/5776
considering this a good PoC and realistic to merge. Then could increment from there even up to fully replacing checkstyle, automating all its features.
Whatever the code style we pick I want an Intellij config that will format the code to be compliant code. And Maven's CI profile should only check for compliance without changing any code. Ideally Maven wouldn't do any rewrite unless prompted explicitly. Maybe while we're at it we could have a git pre-commit setup that calls the formatter? Wdyt @adangel
Its all related and spot the solution to all:
If using Spotless is the solution to everything please stop opening new issues about it, we're already talking about it here. Let's discuss it here and stop dispersing.
pre-commit setup
This could be complex, as Spot takes some time, while committing is a fast and frequent task. Assuming every commit would then somehow execute mvn spotless:apply.
Despite that, I’ve experienced in some projects that hooks failed to ensure Conventional Commits. They were installed in my Git but still not enforced.
Yes, having it run in the cloud only makes sense for the verify goal.
We should be able to detect runs on a dev machine and only execute the apply goal there—assuming it’s cheaper to just fix the build, invest a little time upfront, and avoid the risk of failing CI due to avoidable fixes.
This would also reduce the need for manual interaction by executing some dedicated profile.
Quarkus build has a parameter no-format. There are many smart ways to do so. As its similar to checkstyle, why not simply execute in same phase the apply goal and ensure with verify in the cloud.
https://github.com/quarkusio/quarkus/blob/7b789e354dfde7bb5f692719bd9cdea758a8e1b5/build-parent/pom.xml#L691
Maven and Quarkus both deliver the fixes "out of the box," executed silently when passing the verify goal. Some even argue to fail compilation—considering Nessie:
- https://github.com/projectnessie/nessie/pull/624
Intellij config
This is very specific but understandable, assuming we all use IDEA.
Its all there, we just need to use is.
- https://plugins.jetbrains.com/plugin/13180-palantir-java-format
- https://github.com/palantir/palantir-java-format
maven does not apply auto fix on cloud like expected:
- https://github.com/apache/maven-parent/blob/f4ab7c2eb04865071186c57a263243c72b6e8d52/pom.xml#L1415C11-L1415C30
- https://github.com/apache/maven-parent/blob/f4ab7c2eb04865071186c57a263243c72b6e8d52/pom.xml#L1419
in gradle its one simple if and its done: its differently executed, the result is always the same.
- https://github.com/diffplug/spotless/pull/2528
if (System.env['CI'] == null) {
tasks.named('spotlessCheck') {
dependsOn 'spotlessApply'
mustRunAfter 'spotlessApply'
}
}
I'm going to change this issue to a discussion topic and change the subject to "Improve Developer Experience". Then we can collect the things that can be improved, discuss what/where/how to improve it and so on.