Great job! while we are here and changing format to something more compact. I wonder if we could remove those extra (useless?) spaces such: providers.add( requireNonNull( service, "service instance cannot be null" ) );
On Sat, 15 Oct 2022 at 17:50, Guillaume Nodet <[email protected]> wrote: > > Le ven. 14 oct. 2022 à 22:14, Jochen Wiedmann <[email protected]> a > écrit : > > > Hi, Guillaume, > > > > rather than suggesting (and, what's worse: discussing) code change > > details: Is there, by any change, an existing code style, that we > > might adopt? In particular.could we reuse tools, like an Eclipse > > fornatter, and the like? > > > > Definitely, see the other discussion about automatic formatting [1]. > > My idea is to do both at the same time. I.e. set up what is needed to have > a way to easily reformat files (either always, as by enabling a profile). > Once that's done on a given project, there is a need to reformat the files > so that the formatting check can pass. The idea is to do a single pass: > first agree that we want to enforce formatting, then agree on the format we > want. Once that's settled, It should be easy to set up when a project > migrates. > > Currently, my proposal is to leverage the existing eclipse configuration > file (that can be downloaded from the web site at [2]) and to apply that > config using spotless plugin (it uses the eclipse formatter underneath, > pointing to those very files) to reformat. This could be done very easily > using a modification in the maven parent, see [3]. So the tools are there > and they are easy to use on the command line and the settings can be > imported in Eclipse and IDEA. It's mostly a matter of upgrading the parent > pom to this new version and reformatting everything. After that, > formatting will be enforced and applied easily using the -Pformat profile. > > The above is mainly discussed in the other discussion I mentioned. This > one was more about changing the style, but it definitely needs to be > understood in the context of the other discussion about how to enforce it, > else it's really not interesting imho. > > The question is then which code style configuration do we want. I > personally would love to have a middle ground between the current code > style and the usual java code style. I.e. keep spaces the way they are, but > do not enforce line breaks for each opening / closing braces. I've just > raised a draft PR at [4] as an early proposal. Here's an example of > reformatted code [5]. > > The problem I see is mainly that people kinda fear the automatic formatting > step. Imho, working on maven projects will be easier with an automatic > reformatting during the first phase of the build, rather than trying to > rely on the IDE formatting, just to find out that it does not completely > match the enforced one, trying to fix it manually, then fail again, and > last use the formatter in the build to actually format it correctly. This > could happen if you changed a bit your IDE settings (which can happen if > you switch from a project to another), or if you use an IDE which is not > Eclipse : as close as the format results can be, the only way to have the > exact result is to use the same formatter. I know IDEA has a plugin to use > the eclipse formatter, so that would be a deal saver imho, as there will > always be some discrepancies between the formatters on some tricky code > (mostly very long statements spanning multiple lines, where formatters can > decide to break/indent slightly differently). I very well suspect that > people will just switch to use the automatic format step which is really > fast and just works. As indicated on other threads, some IDE can also > support format-on-save, which would avoid having the source code > reformatted outside the IDE. > > [1] https://lists.apache.org/thread/ok9qdl1w92f9fhdkz3tmc5f65ytpppqp > [2] https://maven.apache.org/developers/committer-environment.html > [3] https://github.com/apache/maven-parent/pull/80 > [4] https://github.com/apache/maven-shared-resources/pull/3 > [5] > https://github.com/gnodet/maven-resolver/blob/reformat/maven-resolver-impl/src/main/java/org/eclipse/aether/impl/DefaultServiceLocator.java > > > > > Apart from that, I'd be more than happy about the changes, that you > > are suggesting. > > > > Jochen > > > > > > On Wed, Oct 12, 2022 at 6:23 PM Guillaume Nodet <[email protected]> wrote: > > > > > > 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 > > > > > > > > -- > > Philosophy is useless, theology is worse. (Industrial Disease, Dire > > Straits) > > > > --------------------------------------------------------------------- > > 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]
