Re: [jdt-dev] A matter of style: loops vs. streams and - gasp - braces

[Andrey Loskutov <loskutov@xxxxxx>]

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
>https://wiki.eclipse.org/Coding_Conventions
>
>The official style guide from Oracle recommends using braces. See
>https://www.oracle.com/technetwork/java/codeconventions-150003.pdf
>page 13.
>
>Quote from the PDF:
>if (condition) //AVOID! THIS OMITS THE BRACES
>statement;
>
>Google Java code style guide also suggest to use braces
>https://google.github.io/styleguide/javaguide.html#s4.1-braces
>
>On Mon, Sep 30, 2019 at 3:02 PM Andrey Loskutov <loskutov@xxxxxx>
>wrote:
>>
>> > > If you debug such code (not written by you), you tend to read
>this
>> > > 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
>should
>> > 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
>>
>> Спасение утопающих - дело рук самих утопающих
>>
>> https://www.eclipse.org/user/aloskutov
>> _______________________________________________
>> jdt-dev mailing list
>> jdt-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or
>unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jdt-dev
>
>
>
>-- 
>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:
>http://www.vogella.com
>_______________________________________________
>jdt-dev mailing list
>jdt-dev@xxxxxxxxxxx
>To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit
>https://www.eclipse.org/mailman/listinfo/jdt-dev

--
Kind regards,
Andrey Loskutov

https://www.eclipse.org/user/aloskutov
Спасение утопающих - дело рук самих утопающих