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 dis
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
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 Intell
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
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 committ
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. 20
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:
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 i
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
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 t
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,
+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 st
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 u
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,
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 g
+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
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
+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 format
+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
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 mor
20 matches
Mail list logo
