Front page | perl.perl5.porters |
Postings from July 2013
On Jul 30, 2013, at 5:56 PM, Karl Williamson <public@khwilliamson.com> wrote:
> 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.
In that particular case I did it because I consider sv_newmortal-then-SvTEMP_off to be a single action. I find it easier to read that way.
> 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.
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).
Thread Previous
|
Thread Next