I think the issue should be kept to reformatting, with minimal intrusions where
the formatter doesn't handle the code well (because the code was hand-aligned
for some purpose - as in javadoc explaining term positions, etc.).
Enforcing braces policy is another thing (that would require a
separate t
I like braces too. For this kind of mass edit though, I’m not about to
start changing anything that isn’t already touched by the formatter,
that’s a never-ending rat-hole and rife with possibilities to screw
up.
What that means in this case is that the formatter changes
if (something)
blah
t
+1 to always braces
On Thu, Dec 24, 2020 at 11:47 AM Michael Sokolov wrote:
> The Google convention you cited says this, I think?
>
> >Braces are used with if, else, for, do and while statements, even
> when the body is empty or contains only a single statement.
>
> On Thu, Dec 24, 2020 at 8
The Google convention you cited says this, I think?
>Braces are used with if, else, for, do and while statements, even when the
> body is empty or contains only a single statement.
On Thu, Dec 24, 2020 at 8:00 AM Dawid Weiss wrote:
>
> > Personally I would ban the non block conditional, but
> Personally I would ban the non block conditional, but I think it's moot in
> this context since spotless just does what it does and is not configurable,
> as I understand it. I suppose we could manually "fix" all the conditionals
> though?
I'm pretty sure you could do it automatically... But
Personally I would ban the non block conditional, but I think it's moot in
this context since spotless just does what it does and is not configurable,
as I understand it. I suppose we could manually "fix" all the conditionals
though?
On Wed, Dec 23, 2020, 9:07 AM Erick Erickson
wrote:
> I took a
> The formatter tightens up non-block comments, i.e.
>
> if (this == obj)
> return true;
>
> becomes
>
> if (this == obj) return true;
Yes, correct.
> Which one is clearer is always a matter of debate, but my take is that braces
> should be added when the _original_ code was on multiple lines,
They both look fine to me, I’d likely go with the default so that there is
less for us to maintain.
On Wed, Dec 23, 2020 at 8:08 AM Erick Erickson
wrote:
> I took a quick look at lucene/queries just to get my feet wet. Before
> working on it seriously. I did a fast scan through about half of the
I like this one,
> if (this == obj) {
> return true;
> }
Regards, r00t4dm
Cloud-Penetrating Arrow Lab of Meituan Corp Information Security Department
> 2020年12月23日 下午10:07，Erick Erickson 写道：
>
> I took a quick look at lucene/queries just to get my feet wet. Before working
> on it seriously.
I took a quick look at lucene/queries just to get my feet wet. Before working
on it seriously. I did a fast scan through about half of the changes and have
only one question.
The formatter tightens up non-block comments, i.e.
if (this == obj)
return true;
becomes
if (this == obj) return tr
I added some instructions on how to help out here:
https://issues.apache.org/jira/browse/LUCENE-9570
spotless.gradle has a long list of projects that need to be reviewed.
You can pick a small one and take it from there.
Dawid
On Wed, Dec 23, 2020 at 8:07 AM Dawid Weiss wrote:
>
> It is currentl
It is currently limited to a subset of the code - reformatted the code
that's already formatted, so a no-ip. See exclusions in
spotless.gradle. You need to add the module there and then perhaps
limit to a single package so that the diff is not too overwhelming.
On Tue, Dec 22, 2020 at 11:58 PM Da
I tried to use this on master for a particular module lucene/spatial-extras
to see what happens. I ran "gw tidy" and it ran the tasks but did nothing
discernable. Any clues what to do?
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Tue, Dec 22, 20
Yeah - those single-line comments that were broken are mostly because
they were just too long to fit in a single line. Other blocks (with
shorter single-line
comments) were just fine.
I've seen a couple other oddities resulting from //-type comments
inside statements
or right after variable declar
Yes, that is what I saw; line breaking choices that are different than
what I would manually have chosen. I don't mean to sound negative -
this is a nice improvement that gets us away from having to fuss about
indentation and other formatting. Even regarding these line breaks, it
is sensible to ha
> It is fine, if there are conflicts and will juggle them :)
If you try to merge directly, there will be conflicts. But if you do
what I describe below, it
should require no manual assistance and will ease the pain to
literally zero effort.
// get the latest changes (I assume origin points at apa
> I see it there - yes, it makes some occasional widows, and sometimes
> fails to join up consecutive single-line comments (I think you
> mentioned this elsewhere) but I can live with it :)
I review those diffs manually (for now at least). Some things are indeed
more verbose but I think they can b
Hi Dawid,
It is fine, if there are conflicts and will juggle them :)
thanks for this effort, it is very cool!
On Tue, Dec 22, 2020 at 5:04 PM Michael Sokolov wrote:
> I see it there - yes, it makes some occasional widows, and sometimes
> fails to join up consecutive single-line comments (I
I see it there - yes, it makes some occasional widows, and sometimes
fails to join up consecutive single-line comments (I think you
mentioned this elsewhere) but I can live with it :)
On Tue, Dec 22, 2020 at 10:07 AM Dawid Weiss wrote:
>
> > Looks as if javadoc is likely to be the main challenge?
> Looks as if javadoc is likely to be the main challenge?
Not really - it's all handled fairly well (automatically). I merged your
changes to master branch and reformatted it locally, I'll merge back to master
soon.
Dawid
-
To u
Hmm, I committed my outstanding PR with no conflicts, so I assume you
didn't get the reformatting in yet; let me know if *I* can help :)
-MIke
On Tue, Dec 22, 2020 at 9:06 AM Michael Sokolov wrote:
>
> Thanks for the heads up. If you commit your changes first, I'll tackle the
> reformatting and
Thanks for the heads up. If you commit your changes first, I'll tackle the
reformatting and let you know if I run into issues. Looks as if javadoc is
likely to be the main challenge?
On Tue, Dec 22, 2020, 8:56 AM Dawid Weiss wrote:
> Hi Mike, Ignacio,
>
> Just wanted to let you know that I wante
Hi Mike, Ignacio,
Just wanted to let you know that I wanted to go through the rest of
lucene-core reformatting soon-ish (I've done a lot on the branch
already and a subset of packages ended on master too).
This will touch packages which you've been working on recently. I
don't think it'll be a pr
I am aware of this and I don't intend to touch Solr at the moment.
Dawid
On Thu, Dec 17, 2020 at 5:10 PM Ishan Chattopadhyaya
wrote:
>
> Let's please leave the Solr side until 8.8 is out. Some big changes are in
> flight and I don't want to waste time with the merges to the various branches.
>
Let's please leave the Solr side until 8.8 is out. Some big changes are in
flight and I don't want to waste time with the merges to the various
branches.
On Thu, 17 Dec, 2020, 8:43 pm Timothy Potter, wrote:
> Sounds great Dawid! And sorely needed in this project, thanks for taking
> this on. I'l
Sounds great Dawid! And sorely needed in this project, thanks for taking
this on. I'll do as much as I can on the Solr side ;-)
Cheers,
Tim
On Thu, Dec 17, 2020 at 4:31 AM Dawid Weiss wrote:
> Hey everyone,
>
> Sorry it took me a while but I wanted to get back to LUCENE-9564 and
> applying an a
Hey everyone,
Sorry it took me a while but I wanted to get back to LUCENE-9564 and
applying an automated (and non-configurable) code formatter. This will
cause some disruption to all existing branches and patches so I'd like
to make the process as simple as possible by doing the following:
1) add
tic code reformatting on save
> --
>
> Key: LUCENE-5747
> URL: https://issues.apache.org/jira/browse/LUCENE-5747
> Project: Lucene - Core
> Issue Type: Bug
> C
5747:
-
Commit 1601461 from [~elyograg] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1601461 ]
LUCENE-5747: Prevent automatic code reformatting when saving in eclipse (merge
trunk r1601446)
> Eclipse settings - prevent automatic code ref
5747:
-
Commit 1601446 from [~elyograg] in branch 'dev/trunk'
[ https://svn.apache.org/r1601446 ]
LUCENE-5747: Prevent automatic code reformatting when saving in eclipse
> Eclipse settings - prevent automatic code ref
tomatic code reformatting on save
> --
>
> Key: LUCENE-5747
> URL: https://issues.apache.org/jira/browse/LUCENE-5747
> Project: Lucene - Core
> Issue Type: Bug
>
tomatic code reformatting on save
> --
>
> Key: LUCENE-5747
> URL: https://issues.apache.org/jira/browse/LUCENE-5747
> Project: Lucene - Core
> Issue Type: Bug
>
n my timezone, UTC-6) if there are no
objections.
> Eclipse settings - prevent automatic code reformatting on save
> --
>
> Key: LUCENE-5747
> URL: https://issues.apache.org/jira
ent automatic code reformatting on save
> --
>
> Key: LUCENE-5747
> URL: https://issues.apache.org/jira/browse/LUCENE-5747
> Project: Lucene - Core
> Issue Type: Bug
, disabling all such
actions.
> Eclipse settings - prevent automatic code reformatting on save
> --
>
> Key: LUCENE-5747
> URL: https://issues.apache.org/jira/browse/LUCENE-5747
>
Shawn Heisey created LUCENE-5747:
Summary: Eclipse settings - prevent automatic code reformatting on
save
Key: LUCENE-5747
URL: https://issues.apache.org/jira/browse/LUCENE-5747
Project: Lucene
36 matches
Mail list logo
