[
https://issues.apache.org/jira/browse/LUCENE-9564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss updated LUCENE-9564:
--------------------------------
Description:
This is a trivial change but a bold move. And I'm sure it's not for everyone.
I started using google java format [1] in my projects a while ago and have
never looked back since. It is an oracle-style formatter (doesn't allow
customizations or deviations from the defined 'ideal') - this takes some
getting used to - but it also eliminates *all* the potential differences
between IDEs, configs, etc. And the formatted code typically looks much better
than hand-edited one. It is also verifiable on precommit (so you can't commit
code that deviates from what you'd get from automated formatting output).
The biggest benefit I see is that refactorings become such a joy and keep the
code neat, everywhere. Before you commit you just reformat everything
automatically, no matter how much you messed it up.
This isn't a change for everyone. I myself love hand-edited, neat code... but
the reality is that with IDE support for automated code changes and so many
people with different styles working on the same codebase keeping it neat is a
big pain.
Checkstyle and other tools are fine for ensuring certain rules but they don't
take the burden of formatting off your shoulders. This tool does.
Like I said - I had *great* reservations about using it at the beginning but
over time got so used to it that I almost can't live without it now. It's like
magic - you play with the code in any way you like, then run formatting and
it's nice and neat.
The downside is that automated formatting does imply potential merge problems
in backward patches (or any currently existing branches).
Like I said, it is a bold move. Just throwing this for your consideration.
I've added a PR that adds spotless but it's not ready; some files would have to
be excluded as they currently violate header rules.
A more interesting thing is here where the current code is automatically
reformatted, for eyeballing only.
https://github.com/dweiss/lucene-solr/commit/80e8f14ca61a13781bc812967a9e38cdbe656041
[1] https://google.github.io/styleguide/javaguide.html
was:
This is a trivial change but a bold move. And I'm sure it's not for everyone.
I started using google java format [1] in my projects a while ago and have
never looked back since. It is an oracle-style formatter (doesn't allow
customizations or deviations from the defined 'ideal') - this takes some
getting used to - but it also eliminates *all* the potential differences
between IDEs, configs, etc. And the formatted code typically looks much better
than hand-edited one. It is also verifiable on precommit (so you can't commit
code that deviates from what you'd get from automated formatting output).
The biggest benefit I see is that refactorings become such a joy and keep the
code neat, everywhere. Before you commit you just reformat everything
automatically, no matter how much you messed it up.
This isn't a change for everyone. I myself love hand-edited, neat code... but
the reality is that with IDE support for automated code changes and so many
people with different styles working on the same codebase keeping it neat is a
big pain.
Checkstyle and other tools are fine for ensuring certain rules but they don't
take the burden of formatting off your shoulders. This tool does.
Like I said - I had *great* reservations about using it at the beginning but
over time got so used to it that I almost can't live without it now. It's like
magic - you play with the code in any way you like, then run formatting and
it's nice and neat.
The downside is that automated formatting does imply potential merge problems
in backward patches (or any currently existing branches).
Like I said, it is a bold move. Just throwing this for your consideration.
I've added a PR that adds spotless but it's not ready; some files would have to
be excluded as they currently violate header rules.
A more interesting thing is here where the current code is automatically
reformatted, for eyeballing only.
https://github.com/dweiss/lucene-solr/commit/80e8f14ca61a13781bc812967a9e38cdbe656041
> Format code automatically and enforce it
> ----------------------------------------
>
> Key: LUCENE-9564
> URL: https://issues.apache.org/jira/browse/LUCENE-9564
> Project: Lucene - Core
> Issue Type: Task
> Reporter: Dawid Weiss
> Assignee: Dawid Weiss
> Priority: Trivial
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a trivial change but a bold move. And I'm sure it's not for everyone.
> I started using google java format [1] in my projects a while ago and have
> never looked back since. It is an oracle-style formatter (doesn't allow
> customizations or deviations from the defined 'ideal') - this takes some
> getting used to - but it also eliminates *all* the potential differences
> between IDEs, configs, etc. And the formatted code typically looks much
> better than hand-edited one. It is also verifiable on precommit (so you can't
> commit code that deviates from what you'd get from automated formatting
> output).
> The biggest benefit I see is that refactorings become such a joy and keep the
> code neat, everywhere. Before you commit you just reformat everything
> automatically, no matter how much you messed it up.
> This isn't a change for everyone. I myself love hand-edited, neat code... but
> the reality is that with IDE support for automated code changes and so many
> people with different styles working on the same codebase keeping it neat is
> a big pain.
> Checkstyle and other tools are fine for ensuring certain rules but they don't
> take the burden of formatting off your shoulders. This tool does.
> Like I said - I had *great* reservations about using it at the beginning but
> over time got so used to it that I almost can't live without it now. It's
> like magic - you play with the code in any way you like, then run formatting
> and it's nice and neat.
> The downside is that automated formatting does imply potential merge problems
> in backward patches (or any currently existing branches).
> Like I said, it is a bold move. Just throwing this for your consideration.
> I've added a PR that adds spotless but it's not ready; some files would have
> to be excluded as they currently violate header rules.
> A more interesting thing is here where the current code is automatically
> reformatted, for eyeballing only.
> https://github.com/dweiss/lucene-solr/commit/80e8f14ca61a13781bc812967a9e38cdbe656041
> [1] https://google.github.io/styleguide/javaguide.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
