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

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


Back to the top