4 ms·

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 any

• swift 10y ago
  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.
  • paulddraper 10y ago
    "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.
    • taeric 10y ago
      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).
      • paulddraper 10y ago
        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.
        • taeric 10y ago
          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. :)
    • loeg 10y ago
      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.
      • chris_wot 10y ago
        Does this make it a moo-t point?
      • paulddraper 10y ago
        Also a strong argument for Python's syntax :)
        • Grue3 10y ago
          Except in Python both the incorrect and correct code are syntactically valid and the error cannot be detected by auto-formatter.
• __david__ 10y ago
  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 @
  • nitrogen 10y ago
    Try rotating your screen 90 degrees.
    • chris_wot 10y ago
      Do you know how weird that makes me look when I'm coding on my laptop at the airport?
      • nitrogen 10y ago
        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.
  • echlebek 10y ago
    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?
• __david__ 10y ago
  Because one takes an extra line. For something that's effectively not the point of the code. There's no reason errors should take up so much vertical code space (which is at a premium even today, given how wide monitors are). I much prefer errors going out wide, so you can mentally skip them when learning code, but zoom in when they are the thing you are checking. This, incidentally, is one of my primary quibbles with golang, and why I will never give in to the community's slavish devotion to "go fmt" in my own go code.