+1 thanks for bringing up this topic Enrico
Il giorno gio 13 ott 2022 alle ore 06:42 Guillaume Nodet <[email protected]> ha scritto: > > Le mer. 12 oct. 2022 à 22:02, Łukasz Dywicki <[email protected]> a écrit : > > > Maybe its time to think of getting something like spotless [1] applied > > to all maven sources? > > > > I think I started the other discussion exactly for that purpose. It's not > specifically about spotless, but that one is just one tool, i was using a > different one to achieve the exact same result : a maven plugin which > reformats during the build. > > > > 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. > > > > Agreed, that's exactly what I'm proposing on the other thread. > > > > > > 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] > > > > > > -- > ------------------------ > Guillaume Nodet --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
