Agree on changing. +1 for spotless. I already used it and it's very convenient! And this will help to fix PRs which will be screwed.
I didn't check in detail the format changes. But can we remove those extra useless spaces as well such: if ( !Files.exists( mojoConfigFile.toPath( ) ) ) On Thu, 13 Oct 2022 at 06:02, Łukasz Dywicki <[email protected]> wrote: > > Maybe its time to think of getting something like spotless [1] applied > to all maven sources? > > I've seen it used in openhab [2] to rule multiple things and it works > well with large codebases with multiple contributors. > > While it looks like there might be a middle ground between all IDEs, > such ground never going to exist for several reasons. Code formatters > have a lot of options, sometimes incompatible, depending on how AST and > processing is being built. There are less popular IDEs/editors who lag > behind, finally there are various sources and maybe exceptions. > Spotless seems to be good in doing it as an external tool which is able > to format and verify (limited) set of sources. > > Best, > Łukasz > > [1] https://github.com/diffplug/spotless/tree/main/plugin-maven > [2] https://github.com/openhab/static-code-analysis > > On 12.10.2022 20:54, Arnaud Héritier wrote: > > +1. > > > > If useful we can also add an editorconfig file to automatically configure > > IDEs but it’s a bit redundant with checkstyle > > > > > > Le mer. 12 oct. 2022 à 18:24, 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 > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
