On Tue, 30 Jul 2013 23:35:27 -0400, Uri Guttman <uri@stemsystems.com> wrote: > On 07/30/2013 08:56 PM, Karl Williamson 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. > > > > 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. > > in my 20 years of heavy c (but rusty now thanks to perl) i always used > braces on if. i always espoused that for safety, clarity, ease of safety is bullshit. using braces does not produce code that runs safer than when braces are omitted. I hear that argument way too often. If however you mean safety as that the programmer is less likely to make errors, it is the programmer that might be hinted, not the code. Clarity is in the eye of the beholder. Some find it clearer, some don't. Ease of changes. Yes obviously. > changes, etc. it also makes it easier to skip code sections with emacs True *only* if the braces enclose multiple statements (which is what they are there for). If having just one statement, honestly say: dis your *ever* use your editors function to skip that "block"? Having no braces would make that a single arrow key or return, having braces two or three > by skipping paired chars. of course there was some lout who claimed if > it is legal c it is ok code. > > braces += Inf ; {*unneeded* braces} -= Inf; -- 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