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

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

Thread Previous | Thread Next
From:
Karl Williamson
Date:
July 31, 2013 00:56
Subject:
Using braces on 'if'; Was: Re: Asan help request
Message ID:
51F860AE.6080503@khwilliamson.com
On 07/25/2013 02:19 AM, Nicholas Clark wrote:
> I don't think that using a comma operator in void context just to avoid
> needing braces is really worth it. It doesn't feel like idiomatic C.

I agree, and I'd like to put in a plug for using braces.

The coding standards where I $worked called for always using braces when 
the 'then' clause was not on the same line as its 'if'.  The reason was 
bitter experience with maintenance safety.  It's too easy for someone to 
later come in and fail to notice the absence of braces, and turn this:

	if (a)
	   b;

into
	if (a)
            c;
            b;

Thus causing b to be executed unconditionally, contrary to the original 
code.  If you're lucky this will generate a compiler warning or error 
(as happened to me on Saturday with the Perl core).  If you're somewhat 
less lucky, the regression tests will have adequate coverage and you'll 
find this problem almost immediately.  But if you're unlucky, this 
regression won't be found until an angry customer and boss are breathing 
down your neck.  Under such pressure (or even without), code reading may 
very easily fail to see what is the problem.  Our eyes look at the 
indentation, and not the lack of braces.  This happened enough that we 
banned the practice, and everybody got into the habit of always saying
	
	if (a) {
	   b;
	}

That habit has saved me from creating many bugs over the years.

I had thought that Perl coding standards forbid this

	if (a) b;  /* I thought this was not acceptable */

But I don't see a statement in the current perlhack about it.  But I 
don't see very many examples of it in the Perl core, so it appears to be 
a defacto standard.  The reason I know to avoid this construct is 
because if you're using the debugger, you can't set a breakpoint on b 
(at least not easily; if 'a' is evaluatable in the debugger, you can 
emulate a breakpoint at 'b', if the consequent execution time slow-down 
isn't too large).  Maybe there are other reasons.  I can see arguments 
about it being easier to follow the logic.

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