Hacker News new | ask | show | jobs
by shawnz 2682 days ago
Why? Because Apple had a critical vuln one time which was made slightly harder to spot because of it?
3 comments

When drafting a style guide, one of your goals is to make the code as uniform as possible. It removes ambiguity and makes it easier to enforce the rules of the style guide, hopefully with automated tooling.

Mandatory bracing is a step towards more uniformity, and makes additional statements in a conditional block always safe, and at the cost of just one extra line in the code.

It also makes your commits just a little bit smaller; if you do add more lines to a conditional block that was previously braceless, now you just get the new lines in the diff, instead of new lines + opening brace + closing brace.

Cowboy coding of course scoffs at all this and people have different values when making tradeoffs between readability and concision, but there are good reasons for enforcing mandatory braces.

The uniformity argument becomes rather silly when applied to other constructs.

Would you ditch switch-cases in favor of if-else chains (leaving aside fallthrough/Duff's/etc for a moment) because the latter is uniform with existing constructs? Would you ditch "for (int i = 0; ..." in favor of "int i; for (i = 0; ..."?

> Would you ditch switch-cases in favor of if-else chains

No. You're talking about applying style rules for if-else conditionals to statements which aren't if-else, which isn't what I was talking about.

This is why the Linux kernel style guide, OpenBSD style, PSR, etc. all have separate guidelines for switch-case along with guidelines for mandatory bracing in if-else.

> Would you ditch "for (int i = 0; ..." in favor of "int i; for (i = 0; ..."?

There isn't a clear-cut rule about this convention in style guides. That's probably in part because the behavior in your two examples is different: in the first case (in C++), i only exists within the scope of the for loop, whereas in the latter case it will continue to exist outside the scope of the for loop.

Whichever one is appropriate would probably depend on context that's outside the scope of a style guide. They're called style guides, after all, not Programming Rules of Law. :-)

You can think of 1 high profile incident. But the failure is easy to overlook. Why do you think that there aren't more? (Also, I'm pretty sure I've seen others like this in the news; it's not "one time" caught)
If I had a penny for each of these coding errors I have personally fixed, across various projects and languages, I would probably have...about a dollar. Which, IMNSHO, allows me to sufficiently extrapolate that this error is extremely widespread, and to speculate that it might be lurking in other critical locations.