User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2
The PR looks well, I am just putting
static imports AFTER non-static, Arjan does exactly opposite (like
Google :-D), we can vote.
On large classes it is easier to go to
the top of the file, on smaller is better to have constants closer
to the class name. So it depends ...
I had to google the google rules, just
quick question - what exactly you don't like so much? I think I
did not like something too, but I cannot remember what.
Please note I didn't mention automatic code changes
(because I don't like it too :) )
My preference is to have only check bind to the default
maven lifecycle. (at least in CI by using a profile so any
PR not respecting the format will not be merged)
Or activated per default but if you don't like you can
disable it locally with a profile even if using mvn
spotless:apply is very cheap to run even if you are
developing something.
I am also not a big fan of the automatic code
formatting, when I am close to completing changes my cycle
is closer to:
1. Code
2. Commit
3. Build and Test
4. Push and PR
I iterate on the first three as I finish off a
change, I have been caught in the past where a build
step is making code changes which are now not in the
commit. The reason I got into this testing was so that
what I was building and testing represented the changes
I was proposing.
Projects however that check the formatting would be
detected in the build step.
First thing I usually do on every project is
running my bash script which replaces tabs with
spaces in selected file types and trims trailing
spaces. It makes a huge difference to GIT and
potential conflicts.
Also if there's a development in more parallel
branches, it can be executed in all of them
independently, BUT it is not possible to do
cherrypicks from the history any more.... It is, but
you have to fix conflicts.
I am not a fan of automatic formatting, but in
the case of the TCK everything is better than the
current state.
Maybe instead of discussion we can prepare some
"prototype" first and then discuss if it is what we
want.
On
Tue, Nov 22, 2022 at 12:43 AM Olivier
Lamy <olamy@xxxxxxxxxxx>
wrote:
What about using some
tool such as spotless [1] which can
apply formatting automatically and
so we don't have to worry about this
while changing the code?
How would we run spotless tool against the master
branch? I see something called sbt on https://github.com/moznion/sbt-spotless,
is that the command line version of spotless tool
that might work against master branch?