Re: [DISCUSS] Change maven code style
On 20/10/2022 at 10:52:41 AM, Olivier Lamy wrote: > definitely +1 for palantir. > Having been trusted with clang-format on a few things - tried out spotless/pantir on a small project. +1 on that - it’s nice, tho - I wish it could be 2 space indents, going back to 4 spaces I suspect will be disruptive for my own needs - but probably not so Maven’s. Interestingly - I see it doesn’t support the new Java text-blocks either (one of my bugbears on clang-format currently). Mark -- "Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree
Re: [DISCUSS] Change maven code style
On Wed, 19 Oct 2022 at 17:05, Guillaume Nodet 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 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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Change maven code style
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
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.
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 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
Re: [DISCUSS] Change maven code style
For my own 2c, all the extra spacing drives me bananas.
Gary
On Mon, Oct 17, 2022, 09:26 Björn Raupach wrote:
> As someone who has just started opening some PRs for Maven, I would
> appreciate a more common Java Code Style.
>
> Not saying the style is bad, it is just confusing. Especially the C++
> like braces on a new line and the additional space between brackets.
>
> Not sure this will help gaining more committers.
>
> Am 12.10.2022 18:23 schrieb Guillaume Nodet:
> > 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: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
Re: [DISCUSS] Change maven code style
As someone who has just started opening some PRs for Maven, I would
appreciate a more common Java Code Style.
Not saying the style is bad, it is just confusing. Especially the C++
like braces on a new line and the additional space between brackets.
Not sure this will help gaining more committers.
Am 12.10.2022 18:23 schrieb Guillaume Nodet:
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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Change maven code style
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 wrote: > > Le ven. 14 oct. 2022 à 22:14, Jochen Wiedmann 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 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
Re: [DISCUSS] Change maven code style
Le dim. 16 oct. 2022 à 10:11, Hervé Boutemy a
écrit :
> key prerequisite is to make sure we don't screw history with the big
> reformat
> commits: I absolutely need to keep git blame provide useful feedback.
>
Right, good point.
> it seems git blame --ignore-revs in Git 2.23 does what we need:
> https://michaelheap.com/git-ignore-rev/
I did not know that feature, it seems to work quite well for us !
Does anybody have experience with this and its support in different
> extended
> tools, like GitHub
> https://github.blog/changelog/2022-03-24-ignore-commits-in-the-blame-view-beta/
> or IDEs?
>
> I'd prefer we test on one non-sensitive small Git repo before doing such a
> change in the important ones
>
I did it on my maven-resolver fork, just adding the git blame [1] and the
output [2] looks quite nice and ignores the previous reformat commit.
Guillaume
[1]
https://github.com/gnodet/maven-resolver/commit/3d6ea3b53cc3ace7ae8206a0095f3b30d9130efa
[2]
https://github.com/gnodet/maven-resolver/blame/reformat/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultRepositorySystem.java
Regards,
>
> Hervé
>
> Le mercredi 12 octobre 2022, 18:23:38 CEST Guillaume Nodet 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: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
--
Guillaume Nodet
Re: [DISCUSS] Change maven code style
key prerequisite is to make sure we don't screw history with the big reformat
commits: I absolutely need to keep git blame provide useful feedback.
it seems git blame --ignore-revs in Git 2.23 does what we need:
https://michaelheap.com/git-ignore-rev/
Does anybody have experience with this and its support in different extended
tools, like GitHub
https://github.blog/changelog/2022-03-24-ignore-commits-in-the-blame-view-beta/
or IDEs?
I'd prefer we test on one non-sensitive small Git repo before doing such a
change in the important ones
Regards,
Hervé
Le mercredi 12 octobre 2022, 18:23:38 CEST Guillaume Nodet 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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Change maven code style
The only way this makes sense if it's fully automatic: all code is
formatted on merge, period, without extra commits or human thought.
Anything less is a big -1 from me.
On Wed, Oct 12, 2022 at 4:24 PM Guillaume Nodet 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
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Change maven code style
Le ven. 14 oct. 2022 à 22:14, Jochen Wiedmann 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 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
Re: [DISCUSS] Change maven code style
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?
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 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
Re: [DISCUSS] Change maven code style
+1
thanks for bringing up this topic
Enrico
Il giorno gio 13 ott 2022 alle ore 06:42 Guillaume Nodet
ha scritto:
>
> Le mer. 12 oct. 2022 à 22:02, Łukasz Dywicki 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 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: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
>
> Guillaume Nodet
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Change maven code style
Le mer. 12 oct. 2022 à 22:02, Łukasz Dywicki 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 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: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
--
Guillaume Nodet
Re: [DISCUSS] Change maven code style
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 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 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: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Change maven code style
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 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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Change maven code style
+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 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
>
--
Arnaud Héritier
Twitter/GitHub/... : aheritier
Re: [DISCUSS] Change maven code style
Non-binding +1 from me.
Gary
On Wed, Oct 12, 2022, 12:23 Guillaume Nodet 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
>
Re: [DISCUSS] Change maven code style
+1 for moving braces to the end line, it is difficult especially with
lambda expression
śr., 12 paź 2022 o 18:52 Tamás Cservenák napisał(a):
> +1 for this formatting change.
>
> T
>
> On Wed, Oct 12, 2022, 18:23 Guillaume Nodet 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
> >
>
--
Sławomir Jaranowski
Re: [DISCUSS] Change maven code style
+1 for this formatting change.
T
On Wed, Oct 12, 2022, 18:23 Guillaume Nodet 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
>
[DISCUSS] Change maven code style
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
