Hacker News Reader

Comment by ja30278 | Hacker News Reader

It's quite funny, but..

" The followers advice is dropping the curly brackets for these one-line ifs to make them all happy. "

I have never understood why anyone would do this. It's a bug waiting to happen (as goto fail showed), for truly marginal benefit

    if (foo)
      bar();

    if (foo) { 
      bar();
    }

View on HN

I agree, but to be fair, goto fail was not really caused by the lack of curly braces around an if statement body. It was caused by inadequate code review and lack of testing coverage. The latter especially is inexcusable in security-critical code.

"The building's collapse was not caused by poor choices in materials, but by inadequate inspection procedures."

Any number of things could have prevented the bug. So lets do all of them.

That logic clearly fails, though. You will never do everything to prevent a failure. (As an example, there are almost always stronger materials. Cost is a requirement,)

Though, your point here is interesting. Using curlies probably could have stopped that bug. Using static analysis that saw dead code definitely would have stopped it.

In this case, mechanisms (automatic checking for dead code) are vastly superior to good intentions (always using curlies).

You're right.

I didn't mean literally everything. I mean everything that has more benefits than costs. I consider consistent curly brace style to fit in that category.

Consistent is nice. There are place where it is consistent to not use them, though.

And to be clear, I find that just as weird as you probably do. :)

Out of millions of CVEs, one is plausibly related to this coding style. I don't think that's a strong argument for using the more verbose style. If we saw this all the time it might be a different matter.

I think it is a strong argument for compilers' -Wall to detect misindented statements directly following unbracketed conditional expressions, though.

Does this make it a moo-t point?

Also a strong argument for Python's syntax :)

Except in Python both the incorrect and correct code are syntactically valid and the error cannot be detected by auto-formatter.

Because one takes an extra line. For something that's effectively an error condition. There's so reason errors should take up so much vertical code space (which is at a premium even today, given how wide monitors are). This is one of my primary quibbles with golang, and why I will never give in to the community's slavish devotion to "go fmt @

Try rotating your screen 90 degrees.

Do you know how weird that makes me look when I'm coding on my laptop at the airport?

No doubt it's quite weird, but I am of the opinion that hardware should serve the code and coder, not the other way around. Maybe use a portrait orientation tablet with a bt keyboard for travel. I think there could be a small market for laptops with a portrait mode, too.

Yikes. Do you realize how useful it is to have a single consistent formatting for source code? It eliminates an entire class of arguments. Or do you enjoy arguing about tabs and spaces, and when to make newlines?

Reply on news.ycombinator.com