Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jdt-dev] A matter of style: loops vs. streams and - gasp - braces

Thanks Lars for pointers. 

Interesting case where me, Oracle and Google all agree on same topic (not that I would care otherwise, but good to know :o)
I guess they also were beaten by this, not just me.

Am 30. September 2019 15:10:03 MESZ schrieb Lars Vogel <lars.vogel@xxxxxxxxxxx>:
>Eclipse code guideline is to follow the Oracle conventions, see
>The official style guide from Oracle recommends using braces. See
>page 13.
>Quote from the PDF:
>if (condition) //AVOID! THIS OMITS THE BRACES
>Google Java code style guide also suggest to use braces
>On Mon, Sep 30, 2019 at 3:02 PM Andrey Loskutov <loskutov@xxxxxx>
>> > > If you debug such code (not written by you), you tend to read
>> > > wrong:
>> > >
>> > >        for (X x : coll)
>> > >            if (isGood(x))
>> > >                process(x);
>> > >                andProcess(y);
>> >
>> > I guess this might happen for bad code of (hopefully) non-eclipse
>> > projects. With automatic code formatting these kind of things
>> > not happen in practice. I guess JDT is also using project specific
>> > settings to enforce automatic formatting on save, right?
>> The only difference of braces / no braces approach is ONE SINGLE LINE
>needed additionally.
>> Is this really worth the risk to have broken code?
>> In an ideal world all people on a project use same (Eclipse based)
>tooling with same project settings etc, work on a single branch and
>develop separated code peaces.
>> In my world, even if we have a *strict* and *enforced* project
>settings across our lab etc we still have people touching same code on
>different branches in parallel, and *other* people merging this code
>somewhere on a *different* branch with vi/emacs/whatever merge editor
>that never heard about Eclipse project settings, and because we also
>have changes across multiple, non-Eclipse managed components too.
>> We have ~100 merges at day, I can't ask release managers to use
>Eclipse for merge purpose only to get those braces right, especially if
>Eclipse would first need to recompile the software that needs ~1-2 ours
>or so to get rid of errors.
>> Therefore the safest solution we found (absolutely fool proof) is
>simply to use braces, and it works perfectly, with no one complained so
>far about readability of our code in this area.
>> This is really not worse from readability point of view, and it also
>off-load your brain that does not need extra cycles to check if the
>line indent matches control flow or vise versa.
>> Kind regards,
>> Andrey Loskutov
>> Спасение утопающих - дело рук самих утопающих
>> _______________________________________________
>> jdt-dev mailing list
>> jdt-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or
>unsubscribe from this list, visit
>Eclipse Platform project co-lead
>CEO vogella GmbH
>Haindaalwisch 17a, 22395 Hamburg
>Amtsgericht Hamburg: HRB 127058
>Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
>USt-IdNr.: DE284122352
>Fax (040) 5247 6322, Email: lars.vogel@xxxxxxxxxxx, Web:
>jdt-dev mailing list
>To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit

Kind regards,
Andrey Loskutov
Спасение утопающих - дело рук самих утопающих

Back to the top