Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library?

Subject: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library?
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-09-09 10:47:13

Pierre Morcello wrote:
> At Stewart Roberts, about "embedded if else" vs "Breakable idiom".
>
> You proposed the "embedded if{}else{}" solution. If I was
> fully pleased
> with it, I would not have dare to propose the 'Breakable'
> idiom solution :-). My concerns are :
>
> When you are embedding if/ else, you got quickly more
> tabs/space to manage.
>
> When you are embedding more than 4 if/else, you have to be
> more careful
> to the right side of your line. Nobody like to scroll left right, and
> it is harder to print or display on your website ^^. Even more if you
> got a 10' screen.

You're assuming the need to nest each if/else, which is often not required.  You're also addressing this approach in isolation, when it is often combined with factoring out subfunctions.

> When you are using the 'Breakable' idiom, your code is
> vertically structured, and looking extremely homogeneous.

That is a nice benefit.
>
> The "test", "fail case" and the "ok case" looks more
> contiguous. These are not
> separated by the other tests or the "}else{". There are less
> "visuals parasite" between them.

Errors are often handled by throwing exceptions.  When they aren't, they may be handled by early returns.  When that doesn't apply, they are rightfully relegated to the end of the function out of the main code path.  Consequently, I consider this a straw man argument.

> Have a look :

Perhaps you format your code as you showed it, but I think you've indented to try to make things look as bad as possible.  I certainly don't write code as you did.  I removed the excess blank lines to present things better.

> if(t1)
> {
>       if(t2)
>       {
>             if(t3)
>             {
>                   if(t4)
>                   {
>                         if(t4)
>                         {
>                         }
>                         else
>                         {
>                         }
>                   }
>                   else
>                   {
>                   }
>             }
>             else
>             {
>             }
>       }
>       else
>       {
>       }
> }
> else
> {
> }
>
> Breakable
>
> {
>       if(!t1)
>       {
>             break;
>       }
>       if(!t2)
>       {
>             break;
>       }
>       if(!t3)
>       {
>             break;
>       }
>       if(!t4)
>       {
>             break;
>       }
>       if(!t5)
>       {
>             break;
>       }
> }

As written, it would appear that there's nothing to be done following the "breakable" scope, so I would just change "break" to "return" and be done with it.

> The breakable code is easier to maintain : you can add a test and a
> else without "re-tabbing" the code, and also without needing
> to scroll up/down to make the
> visual correspondance between a "if " and a "else" that are
> separated by 4
> tests.

Your example is a worst case which I rarely see.  Early returns and subfunctions easily restructure most of the formatting issues you note and can increase cohesion and decrease coupling.

> As a consequence, I consider The 'Breakable idiom' often
> improves readability for theses tasks, over the embedded if{}else{}.

If you often encounter such situations, then you may well be writing your logic in a way that makes things more awkward than necessary.  Nevertheless, if that's the way you feel presents your logic most clearly, your "breakable" approach does offer an option.

> Also, compared to the expanded version (for(bool executed=false;
> executed!=true; executed =true) or do{...}while(false), the
> 'Breakable macro'
> tells why it is here : it suppresses doubts. I suppose most of my
> coworker would ask me why there is a "do{...}while(false)" in
> some code, while on
> the contrary, it took them no pain to understand the use and
> the meaning (when they read it in someone else code) of the macro.

If do { } while (false) is confusing, then you have bigger issues.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.