develooper Front page | perl.perl5.porters | Postings from July 2013

Re: Using braces on 'if'; Was: Re: Asan help request

Thread Previous | Thread Next
From:
H.Merijn Brand
Date:
July 31, 2013 12:42
Subject:
Re: Using braces on 'if'; Was: Re: Asan help request
Message ID:
20130731144121.7f4be59d@pc09.procura.nl
On Wed, 31 Jul 2013 13:20:45 +0200, demerphq <demerphq@gmail.com> wrote:

> On 31 July 2013 09:26, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
> > On Tue, 30 Jul 2013 21:29:49 -0700, Father Chrysostomos
> > <sprout@cpan.org> wrote:
> >
> >> I would prefer that we not have too many rules.  Being able to format code free-style allows for more clarity when things can up vertically:
> >>
> >>     if      (CvROOT(cv))  slab = OpSLAB(CvROOT(cv));
> >>     else if (CvSTART(cv)) slab = (OPSLAB *)CvSTART(cv);
> >>
> >> Also, I don’t find that the extra verbosity of braces really helps.  In Perl the fact that braces are enforced does not increase verbosity, because we have ‘and’ and ‘or’ for control flow.  Do that in C and you get void warnings galore.
> >>
> >> If you do not feel comfortable omitting the braces, then don’t omit them.  But does that have to apply to those of us who do feel comfortable omitting them?  I omit them all the time, and only once has that resulted in a mistake (which was caught very quickly).
> >
> > +Inf to that
> >
> > In code *I* am responsible for, I remove unneeded braces, as they just
> > take away focus from the code I read. They just act as noise.
> 
> Both you and FC overlook that the statement suffers from the dangling
> else problem and the braced form does not.
> 
> There is nothing subjective about this, it is a fact.
> http://en.wikipedia.org/wiki/Dangling_else

Could be. I program for quite a while now and I have never encountered
this problem. Ever.

Whenever in doubt, use braces (and parens, as Tom will add)

There is an additional advantage of NOT using braces when they can be
omitted: there are no style issues with the brace placement :)

If there are no braces

    if (expr)
        statement;

that will cause no visual conflicts with anyone

   if (expr) {
       statement;
   }

   if (expr) {
       statement;
       }

   if (expr)
   {
       statement;
   }

   if (expr)
       {
       statement;
       }

   if (expr)
    {
       statement;
    }

   if (expr)
   {
       statement;
       }

   if (expr)
   {   statement;
   }

   if (expr)
   {   statement;
       }

Pick your battle :)

Of course you can put that in (style) rules, but as FC said, those are
currently quite liberal, and as long as we all program with sanity in
mind, we do not aim at making the core code a golf or obfuscation
contest. the maze of twisty little macros in itself might be hard
enough for many of us.

Which reminds me

Some macros can include braces, and some can not. Some need braces when
used as a statement

   if (expr)
       MACRO_DEF;

can be invalid. whereas

   if (expr) {
       MACRO_DEF;
       }

shall be considered valid. That is why I do not blindly remove unneeded
braces when the style causes visual grief.

We're getting off-topic here

-- 
H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
using perl5.00307 .. 5.19   porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/        http://www.test-smoke.org/
http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About