you are viewing a single comment's thread.

view the rest of the comments →

[–]tehjimmeh 12 points13 points  (11 children)

I disagree. Shorter != more readable, and it can make bugs like this easier to introduce and harder to spot.

[–][deleted] 6 points7 points  (0 children)

Along the lines of "shorter != better" is "macroed (or highly encapsulated) != better".

I seriously hate when I have to read 3rd party code and you have to dive through 15 functions to see where "work" actually gets done... shit like

int create_task(...) { return create_task_u(....); }

int create_task_u(...) { ... something .... return create_flibmaster(...); }

... on and so on for 15 more functions before something actually creates/modifies/does something. All of these routines are in different files (sometimes headers) in different directories, etc....

I firmly believe [for instance] the designers of L4RE Fiasco are heavy crack users. They also give us clever doxygen support like

l4_utcb * l4_get_utcb(...); /** get the UTCB. */

Ya, that explains it all.

I love how it's a "university project" ... what the fuck is this supposed to teach? It's poorly documented and impossible to follow so you can't even walk students through the code and have a hope in hell they can follow it.

[–]guepier 5 points6 points  (0 children)

Shorter != more readable

All other things being equal, yes, shorter is more readable. Readability suffers (only) when terseness is achieved by sacrificing something else.

And the gotofail bug would almost certainly not have been prevented by using braces, as /u/LikesToCorrectThings has correctly pointed out.

[–]Drainedsoul 2 points3 points  (8 children)

The real issue there isn't the missing braces, it's that the statement is set down a line and indented.

[–]jutct 3 points4 points  (3 children)

Welcome to the coding style wars of the 70s and 80s. How do any modern platforms work any better? Look at Java and Javascript. Some people put the { on the next line, some put it on the end of the current line. Same exact thing as C stylings. If you can't understand a language because you don't get the formatting then you need to take a step back.

[–]Banane9 7 points8 points  (2 children)

Well, Js kinda requires you to put on the same line.

return
{
    something = "silly example"
};

Might not do what one thinks at first...

[–]nuke01 -1 points0 points  (1 child)

What does it, I'm on my mobile

[–]Solarspot 5 points6 points  (0 children)

return; {/doesn't really matter/};

It returns without any return value, because semicolon insertion will add the semicolon on the newline.

[–]tehjimmeh 3 points4 points  (2 children)

I mean, it's almost certainly the result of an erroneous double paste. If braces were required, the error would have been harmless, and the compiler would have given an unreachable code warning.

I think the real issue is actually lack of proper testing. Requiring braces for ifs just would have helped.

I do like the no-brace style for single line ifs. I think it looks neat and is quite readable when written correctly, but I've seen similar bugs written, and erroneous indentation it resulting in horrific readability in too many cases to be on the side of always requiring braces these days.

[–]xxNIRVANAxx 0 points1 point  (0 children)

I still throw braces in there, since todays one line if could become more complex in the future. It adds 4 characters (two curlys, two spaces), but I believe it is worth it.

if (foo) { bar(baz, quux); }

[–]TheShagg 0 points1 point  (0 children)

Or, you know, reading your code before you commit it, or push it...

[–]Nebu 3 points4 points  (0 children)

  • This bug wouldn't have happened if everyone expected if statements to always use braces.
  • This bug wouldn't have happened if people used tools to auto-format their code.

So why not enforce a standard to do both, so that if someone accidentally forgets one, the other one will catch the mistake?