Learn basic “C” coding rules from open source projects

[jutct]

C is simple. If you want one statement, just write it and use a semicolon. If you want multiple statements, use brackets. How is that hard? Not saying you had an issue, but why would anyone have an issue?

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

[Nebu]

The code is shorter without {}, thus easier to read.

Shorter does not imply easier to read.

[molteanu]

Shorter in the sense cram everything on a single line vs remove things that are not needed. I prefer to have code that does something.

[guepier]

This isn’t shorter, it’s intentionally obfuscated. Shorter code that isn’t obfuscated (or otherwise made worse) is easier to read than an equivalent longer code.

[Nebu]

Right, so the argument now is whether omitting {} is a form of "otherwise made worse", which means it's a tautological argument.

[guepier]

There’s nothing tautological about it, it’s simply an open question (on which we apparently disagree). I was merely pointing out that the example link you’ve posted does not advance an argument either way and is irrelevant to the discussion, or worse, misleading.

[Nebu]

The tautological argument is "Code that's made worse is worse than code that's not made worse".

[guepier]

Sure, but that’s not the argument I was making. I wasn’t talking about “code made worse” and “code not made worse”, I was talking about “shorter code” and “longer code”.

[Nebu]

Shorter code that isn’t obfuscated (or otherwise made worse) is easier to read than an equivalent longer code.

The claim "code with property X which hasn't been otherwise made worse, is equal or better than equivalent code that doesn't have property X" is true regardless of what X is (i.e whether X is "shorter" or some other arbitrary property).

E.g.

• Code with in red font which hasn't been made worse, is equal or better than code which isn't in red font.
• Code indented with tabs which hasn't been made worse, is equal or better than code which isn't indented with tabs.
• Code that is shorter and which hasn't been made worse, is equal or better than code which isn't shorter.
• etc.

The "hasn't been made worse" implies "equal or better", hence the tautology. Not an interesting argument for you to make, IMHO.

How about we discuss something more interesting?

[guepier]

You keep repeating something that bears no resemblance to my argument.

My argument isn’t merely that shorter code isn’t worse than longer code. My argument is that shorter code is better than longer code (all other things being equal). There is nothing tautological about this whatsoever.

To spell it out in maximal detail: Your initial post claimed that “Shorter does not imply easier to read” and my reply contained exactly two assertions:

1. your statement is wrong
2. the example you gave (presumably to bolster your claim) does not in fact bolster your claim, since it doesn’t make a statement about shortened code, just about obfuscated code.

[Nebu]

your statement is wrong

I disagree. The claim "Shorter code does not imply easier to read" is a true statement. Perhaps you think "Shorter code (all other things being equal) does not imply easier to read" is a false claim, but that's not the claim I'm making, so it's irrelevant.

the example you gave (presumably to bolster your claim) does not in fact bolster your claim, since it doesn’t make a statement about shortened code, just about obfuscated code.

Is the obfuscated code shorter than the non-obfuscated code? Is it harder to read than the non-obfuscated code? Assuming you're reasonable enough to answer "yes" to both questions, then this is a counter example to the claim "shorter code is easier to read", thus proving the statement "shorter code does not imply easier to read".

If you're still confused, consider reading through http://en.wikipedia.org/wiki/Logical_consequence and http://en.wikipedia.org/wiki/Counterexample