Le ven. 14 oct. 2022 à 22:14, Jochen Wiedmann <jochen.wiedm...@gmail.com> 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 <gno...@apache.org> 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: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- ------------------------ Guillaume Nodet
