A matter of style: loops vs. streams and - gasp - braces

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

A matter of style: loops vs. streams and - gasp - braces

Stephan Herrmann-2
Hi team,

(The following debate is as old as the invention of braces, but Java 8 gives a
new twist to it, so please bear with me for minute as I turn your world upside
down).


In a current gerrit I found the following comment:

 > Also add missing braces on loops as necessary.

I doubt that any of those braces where "necessary", otherwise those would have
been bugs, no?


I'd like to actively promote a braceless style for simple loops and ifs for the
following reason:


Since Java 8 and the introduction of streams we have two main options for
writing many things involving iteration over a collection. As a trivial
first-level criterion to choose among the two, everybody uses "conciseness" of
the code.

Take this pattern:
    for (X x : coll) {
        if (isGood(x)) {
             process(x);
        }
    }
vs.
    coll.stream().filter(x -> isGood(x)).forEach(x -> process(x));

Everybody can "clearly see" that the latter variant is "better".


NO, it is not. We simply cheat by choosing a more condensed layout.
In terms of conciseness, this is the winner:
    for (X x: coll) if (isGood(x)) process(x);

Do you see, how the initial example compared apples and oranges??


The stream() variant even has its own drawback: it will severely backfire should
you ever need to debug that code section.


So my proposal is: Let's for a compromise explicitly admit this style:
     for (X x : coll)
         if (isGood(x))
             process(x);

IMHO this is the sweet spot to balance conciseness, readability and debuggability.

For slightly more involved cases I made a habit of using braces for the
outer-most structure, thus delineating a meaningful chunk of code, s.t. like
     for (X parent : coll) {
         if (isGood(parent))
             for (Y child : parent.getChildren())
                  process(child);
     }

Remember, that we provide quick assists for converting to block, should we need
to add more statements to some body.


If you don't like any of this, we should for fairness also forbid braceless
lambdas and enforce line breaks around the lambda body:
    coll.stream().filter(x -> {
        return isGood(x);
    }).forEach(x -> {
        process(x);
    });
This style is suitable for comparison with the old, imperative style (but ugly,
right?)


No, I'm not against lambdas (just a bit wary about debuggability), but visual
comparison between options should be fair :)


Put differently: a loop structure that can be written without braces has the
same mental clarity as a well structure stream-pipeline. Let's please not
penalize such style by unnecessary verbosity.

best,
Stephan
_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: A matter of style: loops vs. streams and - gasp - braces

Andrey Loskutov
Hi Stephan,

I was personally beaten few times (not in my code) by missing braces,
therefore I always prefer this:

      for (X x : coll) {
          if (isGood(x)) {
               process(x);
          }
      }

over this:

       for (X x : coll)
           if (isGood(x))
               process(x);

or this

for (X x: coll) if (isGood(x)) process(x);

or this

       for (X parent : coll) {
           if (isGood(parent))
               for (Y child : parent.getChildren())
                    process(child);
       }


I was beaten in two cases: reading that braceless code with wrong
indents and fixing bad merges / bad refactorings.

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

and this:

for (X x: coll) if (isGood(x)) process(x); andProcess(y);

and also this:

       for (X parent : coll) {
           if (isGood(parent))
               for (Y child : parent.getChildren())
                    process(child);
                    andProcess(parent);
       }

and finally this masterpiece:

       for (X parent : coll) {
           if (isGood(parent))
               process(parent);
               for (Y child : parent.getChildren())
                    process(child);
                    andProcess(parent);
       }

This is because our brain "automatically" prefers indentation over
"invisible" blocks, it sorts the bad indented lines to previous.

If we would use braces, such examples above would be simply not possible.

How this happen: easy. Either people use tabs + spaces mix, and use
different tabs settings, or you had two branches, a merge conflict with
lot of merges and you end with the code that perfectly compiles but does
not what you want.

Therefore I not only recommend to use braces in all cases but also set
this as the save action in our Eclipse settings.

Regarding lambdas: they are there to allow "fluent" code, so if one
needs to use braces in lambdas it a sign that this code should be
refactored to something else.

On 28.09.2019 15:20, Stephan Herrmann wrote:

> Hi team,
>
> (The following debate is as old as the invention of braces, but Java 8
> gives a new twist to it, so please bear with me for minute as I turn
> your world upside down).
>
>
> In a current gerrit I found the following comment:
>
>  > Also add missing braces on loops as necessary.
>
> I doubt that any of those braces where "necessary", otherwise those
> would have been bugs, no?
>
>
> I'd like to actively promote a braceless style for simple loops and ifs
> for the following reason:
>
>
> Since Java 8 and the introduction of streams we have two main options
> for writing many things involving iteration over a collection. As a
> trivial first-level criterion to choose among the two, everybody uses
> "conciseness" of the code.
>
> Take this pattern:
>     for (X x : coll) {
>         if (isGood(x)) {
>              process(x);
>         }
>     }
> vs.
>     coll.stream().filter(x -> isGood(x)).forEach(x -> process(x));
>
> Everybody can "clearly see" that the latter variant is "better".
>
>
> NO, it is not. We simply cheat by choosing a more condensed layout.
> In terms of conciseness, this is the winner:
>     for (X x: coll) if (isGood(x)) process(x);
>
> Do you see, how the initial example compared apples and oranges??
>
>
> The stream() variant even has its own drawback: it will severely
> backfire should you ever need to debug that code section.
>
>
> So my proposal is: Let's for a compromise explicitly admit this style:
>      for (X x : coll)
>          if (isGood(x))
>              process(x);
>
> IMHO this is the sweet spot to balance conciseness, readability and
> debuggability.
>
> For slightly more involved cases I made a habit of using braces for the
> outer-most structure, thus delineating a meaningful chunk of code, s.t.
> like
>      for (X parent : coll) {
>          if (isGood(parent))
>              for (Y child : parent.getChildren())
>                   process(child);
>      }
>
> Remember, that we provide quick assists for converting to block, should
> we need to add more statements to some body.
>
>
> If you don't like any of this, we should for fairness also forbid
> braceless lambdas and enforce line breaks around the lambda body:
>     coll.stream().filter(x -> {
>         return isGood(x);
>     }).forEach(x -> {
>         process(x);
>     });
> This style is suitable for comparison with the old, imperative style
> (but ugly, right?)
>
>
> No, I'm not against lambdas (just a bit wary about debuggability), but
> visual comparison between options should be fair :)
>
>
> Put differently: a loop structure that can be written without braces has
> the same mental clarity as a well structure stream-pipeline. Let's
> please not penalize such style by unnecessary verbosity.
>
> best,
> Stephan
> _______________________________________________
> jdt-dev mailing list
> [hidden email]
> 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
---------------------------------------------
Спасение утопающих - дело рук самих утопающих
---------------------------------------------
_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: A matter of style: loops vs. streams and - gasp - braces

Stephan Herrmann-2
Andrey,

I sure know about all the bad things that _can_ happen, if badly formatted code
is misunderstood. No arguing about that. Well: also braces can be wrongly
indented, which causes the same kind of havoc ...

It's just that in my universe this threat is so tiny (I'd have to turn my brains
inside out to remember even a single instance) that the effort invested against
it feels completely out of proportion. And if you have the problem I'd first
think about investing in sane indentation.

Obviously, your millage differs from mine.

OK, let's call a truce then ...
Stephan

PS: Maybe I should propose to Oracle to introduce short forms of for and if for
fluent imperative programming :)

On 28.09.19 17:06, Andrey Loskutov wrote:

> Hi Stephan,
>
> I was personally beaten few times (not in my code) by missing braces,
> therefore I always prefer this:
>
>       for (X x : coll) {
>           if (isGood(x)) {
>                process(x);
>           }
>       }
>
> over this:
>
>        for (X x : coll)
>            if (isGood(x))
>                process(x);
>
> or this
>
> for (X x: coll) if (isGood(x)) process(x);
>
> or this
>
>        for (X parent : coll) {
>            if (isGood(parent))
>                for (Y child : parent.getChildren())
>                     process(child);
>        }
>
>
> I was beaten in two cases: reading that braceless code with wrong
> indents and fixing bad merges / bad refactorings.
>
> 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);
>
> and this:
>
> for (X x: coll) if (isGood(x)) process(x); andProcess(y);
>
> and also this:
>
>        for (X parent : coll) {
>            if (isGood(parent))
>                for (Y child : parent.getChildren())
>                     process(child);
>                     andProcess(parent);
>        }
>
> and finally this masterpiece:
>
>        for (X parent : coll) {
>            if (isGood(parent))
>                process(parent);
>                for (Y child : parent.getChildren())
>                     process(child);
>                     andProcess(parent);
>        }
>
> This is because our brain "automatically" prefers indentation over
> "invisible" blocks, it sorts the bad indented lines to previous.
>
> If we would use braces, such examples above would be simply not possible.
>
> How this happen: easy. Either people use tabs + spaces mix, and use
> different tabs settings, or you had two branches, a merge conflict with
> lot of merges and you end with the code that perfectly compiles but does
> not what you want.
>
> Therefore I not only recommend to use braces in all cases but also set
> this as the save action in our Eclipse settings.
>
> Regarding lambdas: they are there to allow "fluent" code, so if one
> needs to use braces in lambdas it a sign that this code should be
> refactored to something else.
>
> On 28.09.2019 15:20, Stephan Herrmann wrote:
>> Hi team,
>>
>> (The following debate is as old as the invention of braces, but Java 8
>> gives a new twist to it, so please bear with me for minute as I turn
>> your world upside down).
>>
>>
>> In a current gerrit I found the following comment:
>>
>>  > Also add missing braces on loops as necessary.
>>
>> I doubt that any of those braces where "necessary", otherwise those
>> would have been bugs, no?
>>
>>
>> I'd like to actively promote a braceless style for simple loops and ifs
>> for the following reason:
>>
>>
>> Since Java 8 and the introduction of streams we have two main options
>> for writing many things involving iteration over a collection. As a
>> trivial first-level criterion to choose among the two, everybody uses
>> "conciseness" of the code.
>>
>> Take this pattern:
>>     for (X x : coll) {
>>         if (isGood(x)) {
>>              process(x);
>>         }
>>     }
>> vs.
>>     coll.stream().filter(x -> isGood(x)).forEach(x -> process(x));
>>
>> Everybody can "clearly see" that the latter variant is "better".
>>
>>
>> NO, it is not. We simply cheat by choosing a more condensed layout.
>> In terms of conciseness, this is the winner:
>>     for (X x: coll) if (isGood(x)) process(x);
>>
>> Do you see, how the initial example compared apples and oranges??
>>
>>
>> The stream() variant even has its own drawback: it will severely
>> backfire should you ever need to debug that code section.
>>
>>
>> So my proposal is: Let's for a compromise explicitly admit this style:
>>      for (X x : coll)
>>          if (isGood(x))
>>              process(x);
>>
>> IMHO this is the sweet spot to balance conciseness, readability and
>> debuggability.
>>
>> For slightly more involved cases I made a habit of using braces for the
>> outer-most structure, thus delineating a meaningful chunk of code, s.t.
>> like
>>      for (X parent : coll) {
>>          if (isGood(parent))
>>              for (Y child : parent.getChildren())
>>                   process(child);
>>      }
>>
>> Remember, that we provide quick assists for converting to block, should
>> we need to add more statements to some body.
>>
>>
>> If you don't like any of this, we should for fairness also forbid
>> braceless lambdas and enforce line breaks around the lambda body:
>>     coll.stream().filter(x -> {
>>         return isGood(x);
>>     }).forEach(x -> {
>>         process(x);
>>     });
>> This style is suitable for comparison with the old, imperative style
>> (but ugly, right?)
>>
>>
>> No, I'm not against lambdas (just a bit wary about debuggability), but
>> visual comparison between options should be fair :)
>>
>>
>> Put differently: a loop structure that can be written without braces has
>> the same mental clarity as a well structure stream-pipeline. Let's
>> please not penalize such style by unnecessary verbosity.
>>
>> best,
>> Stephan
>> _______________________________________________
>> jdt-dev mailing list
>> [hidden email]
>> 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
> ---------------------------------------------
> Спасение утопающих - дело рук самих утопающих
> ---------------------------------------------
> _______________________________________________
> jdt-dev mailing list
> [hidden email]
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://www.eclipse.org/mailman/listinfo/jdt-dev

_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: A matter of style: loops vs. streams and - gasp - braces

Christian Pontesegger
In reply to this post by Andrey Loskutov

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

A somewhat compromise to both of your opinions might be to allow to
remove the brackets for the innermost of such loops and ifs:

        for (X x: coll) {
                if (isGood(x)
                        process(x);
        }

From my experience most of these simple statements do not happen
massively nested but rather isolated, like

        if (loggingEnabled)
                log()

        whatEverComesNext()

In the example above we do still keep an empty line after the statement
for clearer readability. Still (to me) it looks nicer than having the
closing bracket there.

Christian


_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: A matter of style: loops vs. streams and - gasp - braces

Andrey Loskutov
> > 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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: A matter of style: loops vs. streams and - gasp - braces

Lars Vogel-2
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 <[hidden email]> 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
> [hidden email]
> 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: [hidden email], Web: http://www.vogella.com
_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: A matter of style: loops vs. streams and - gasp - braces

Andrey Loskutov
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 <[hidden email]>:

>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 <[hidden email]>
>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
>> [hidden email]
>> 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: [hidden email], Web:
>http://www.vogella.com
>_______________________________________________
>jdt-dev mailing list
>[hidden email]
>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
Спасение утопающих - дело рук самих утопающих
_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: A matter of style: loops vs. streams and - gasp - braces

Mateusz Matela
In reply to this post by Andrey Loskutov
Even though it looks like the discussion has concluded, I'd like to
throw in my two cents for the loosing side :)
> The only difference of braces / no braces approach is ONE SINGLE LINE needed additionally.
That's one way to put it. Another way is that in worst case the line
count will increase by 50%! (even more if we considered nested
structures, but that may be going too far).
> Is this really worth the risk to have broken code?
> [...]
> 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.

Maybe it's lack of experience, but I can't see how this rule can be
absolutely fool proof while there's such a high risk of bugs without it.
If there's so much complicated merging that it's easy to mess up
indentation and not put braces where necessary, it's probably equally
easy to mess up by putting a line on the wrong side of a brace.

No one complains about it - but how many are like me, who prefers the
shorter version, but never thought of it as a big deal? :)

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

I think it's a matter of taste (so it makes perfect sense for you as a
lead developer to enforce this rule). For me it's sometimes more
pleasant (and thus less demanding) to read code with less braces. My
personal rule is to skip braces only when header and body take one line
each. And even then I sometimes add braces to emphasize the code is
doing something significant (rather than a simple break or something) or
there's a high chance it will expand in the future.

Regards,
Mateusz

_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: A matter of style: loops vs. streams and - gasp - braces

Stephan Herrmann-2
On 30.09.19 22:31, Mateusz Matela wrote:
> Even though it looks like the discussion has concluded, I'd like to throw in my
> two cents for the loosing side :)

Mateusz, I much appreciate your comment as our formatter expert, i.e., as a
person who certainly cares a lot about code readability.

I knew beforehand that this is not only a highly controversial issue, but also
an issue where conversion of a person from one side of the issue to the other
has rarely been observed, if ever. Remember emacs vs vi debates? :)

The only reason I unearthed this old debate was the idea that comparison with
the functional style since Java 8 could shed a new light on this, but that part
didn't stimulate a lot of insights, so ...

... let's simply agree on not agreeing and get back to work :)
Stephan
_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev