On Wed, 19 Oct 2022 at 17:05, Guillaume Nodet <[email protected]> wrote: > > After having given that more thought, I think it would make sense to simply > reuse an existing formatter. It seems people are keen to align with a more > traditional code style, so I see two possibilities: > * palantir java format [1], a 120 column, 4 spaces indent formatter, well > supported in Intellij IDEA > * google code style [2], a 100 column, 2 spaces indent code style, with > support for IntelliJ and Eclipse >
definitely +1 for palantir. > I would have a stylistic preference on palantir, but I think the google one > has better integration. I also agree with @elharo that this should be fully > automated so that the formatter can be completely enforced. Anything else > will make a developer's life more complicated with no benefits. Especially > with the google one, as I think it always performs a *full* reformat. I > don't have any problem with adding a profile to just check and not reformat > though, but I don't see any benefit, so I'll do that only if people really > want. back discussing this :( really? I like the idea of check and if it falls to manually run some formatter. if people don;t build or do not format before committing the change will fail on CI at check time. so they have to fix it. So we can avoid some complicated checks or extra erroneous scm command to run to check if committers have forgotten to build (e.g formatting) etc.. the only option could be some git hooks (pre commit) but I already experimented this in other oss projects. Frankly it always turns at some mess as it's some native softwares to run (e.g not available on some platforms) and I don’t want to mention those running on with nodejs (which means some much pain because of upgrades etc..) btw some discussions should be done on pom.xml format as those used be 2 spaces format but now master is a mix of 2 and 4 spaces format... > > Guillaume > > [1] https://github.com/palantir/palantir-java-format > [2] https://google.github.io/styleguide/javaguide.html > > Le mer. 12 oct. 2022 à 18:23, Guillaume Nodet <[email protected]> a écrit : > > > Related to the discussion about automatically formatting and sorting > > imports, I think it would be nice, given the big reformat commits if those > > PRs are to be merged, to eventually discuss some changes to those code > > style. In particular, I found out that the code is very sparse and my > > screen is more wide than height, which means I can usually only see 30-40 > > lines of code, where sometime half of them do not really carry any semantic > > (open braces, or things like close brace + else + open brace on 3 lines). > > This makes me scroll a lot even on quite small methods to be able to read > > the full code, and that's a pain imho. > > So I'd like to propose the following changes that would make maven code > > more readable imho (and also closer to the usual java coding style) : > > * move open braces to the end of the previous line on all places > > * allow the else keyword to be directly following a closing brace to > > allow "} else {" to be on the same line > > * eventually relax a bit the checkstyle line length as described in > > https://github.com/gnodet/maven-shared-resources/pull/2. This has not > > much effect, as the formatter will automatically format the lines and wrap > > them at 120. However, in certain cases, the formatter can find in difficult > > to wrap the line (for example with a variable declaration and cast with a > > fully qualified name) and there is either a need to manually force the wrap > > (using an end of line comment for example) or disabling the check with a > > @SuppressWarning( "checkstyle:LineLength" ) annotation. This change only > > removes the checks so that in those rare cases, the formatter can be left > > without any need to force things. > > > > If this is to be accepted, I'd amend the PRs from the other thread to > > follow those changes. > > > > Cheers, > > Guillaume > > > > > > > > > > -- > ------------------------ > Guillaume Nodet --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
