Declaring code style settings in a Java project

Question

In a Java open source project built with Maven, is there a standard way to declare code style settings (such as indentation settings and import order)? I would like that people who import the project in major IDEs (such as Eclipse and IntelliJ IDEA) are able to get their editor configured to follow those settings with as little effort as possible (ideally automatically).

I have considered the following approaches, all not really ideal:

• use an .editorconfig file, which is designed for that. However, support in Eclipse seems basically abandoned and support in IntelliJ is a bit patchy.
• add a Maven plugin in the build, such as the Maven formatter plugin, which accepts a configuration file which follows Eclipse's own format for code style settings. This format also happens to be supported by IntelliJ. However, neither Eclipse nor IntelliJ seem to be able to automatically detect the presence of those code style settings when importing the code as a Maven project. This means that contributors need to manually import those settings in their IDE when setting up the project. This also does not cover import order, which must be handled separately.
• track add IDE configuration files (.idea for IntelliJ, .settings for Eclipse) in Git so that those IDEs can be preconfigured, but that implies maintaining various copies of the same settings in different files, is bound to only cover few IDEs and is prone to conflicting with customizations made by contributors on their side (with the IDE changing those tracked configuration files, which then accidentally end up in commits)
• give up on editor configuration and rely instead on a linter, potentially triggered by a git hook. This means adding instructions to set up such a hook, can potentially cause conflicts with the IDE which tries to enforce another code style and introduces a potentially heavy process that is run on every commit.

Are there better approaches to this problem? Or is it misguided to have this goal in the first place?

• Laiv: which tries to enforce another coding style and introduces a potentially heavy process that is run on every commit. it doesn't if it only works on specific branches and is triggered by specific commands like PR or when certain text is found in the commit message. After all, the style only matters in main/ master.
• pintoch: I'd expect such a linter to also work on feature branches, so that pull requests are submitted in the expected format, no?
• Laiv: Yes, I only wanted to illustrate a possible use case. The thing is, you don't need to format the code after every single commit, only when it matters (IMO, before merging the branch with the main). However, I would insist on formatting code on the client side, even if the process is not straightforward or transparent to the developer. Anyways, PR are reviewed in OS by one or many contributors, so it's a good idea to have stringent criteria for code candidate to end in the main branch. The code format is a good one.

Answer 1

OP did not describe the proposed changes to default format (TAB == three SPACE, maybe?). More importantly, it did not describe the positive benefit which would outweigh the various frictional negatives detailed.

is it misguided to have this goal?

Yes.

Most editors can handle coding rules like "no TABs!" and "no trailing SPACE!" But to encode more subtle details like where the { } curly braces go, you kind of need to put the definitive instructions in one place, either a linter or preferably as pretty-printer styling which a readonly linter can verify. And they must be committed as part of the build process, perhaps run by mvn.

@Laiv's pre-commit suggestion is a good one. All my repos have a .git/hooks/pre-commit script; it's not burdensome. Among other things the scripts check for TABs and trailing SPACE.

Given such a standard belt, developers will seek suspenders that fit their IDE's workflow. A ReadMe can offer helpful advice for popular IDEs, advice that worked at some snapshot in time before the IDE changed. Ultimately each developer will have to explore what works for them at the present time in their IDE on their laptop.

A CI/CD linter should definitely fail the build in the (unlikely?) event that the desired linting gate didn't run properly on a committer's laptop.