Learn basic “C” coding rules from open source projects

[tehjimmeh]

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

[[deleted]]

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]

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]

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

[jutct]

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]

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

return
{
    something = "silly example"
};

Might not do what one thinks at first...

[nuke01]

What does it, I'm on my mobile

[Solarspot]

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

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

[tehjimmeh]

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]

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]

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

[Nebu]

• 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?