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

> > 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

Спасение утопающих - дело рук самих утопающих

Back to the top