Elements of C Style (1994)

▲ Elements of C Style (1994)(teamten.com)

38 points by signa11 5 days ago | 8 comments

▲ unwind 2 days ago | parent | next [-]

This is of course quite old, although C is older so it's not too bad.

I really like the ones in the "Purity" section, and also appreciate the name, I sometimes struggle to express those ideas. To me it's a lot about using the language as if you knew it, not from some strange position of fear that you sometimes see.

My pet peeve in the context is comparing boolean values with boolean literals, i.e.

    const bool success = do_something();
    if (success == true)
    {
    }

which is just horrible in my opinion since the result of an expression like `a == b` is in itself a boolean[*], so it just goes around and around, then! But nobody pretends that is true, since that would lead to

    if ((success == true) == true)

which never happens, so for some reason in people's heads there is some significant difference between that and the first case ... which I find offensive. Always just write

    if (success)

for the win.

Also, since nobody actually uses `const` as much as possible, using the explicit comparison also opens your code to the fantastic typo of:

    bool success = do_something();
    if (success = true)  // Oops!
    {
    }

[*] In C it's more like "an int-type value equal to 0 or 1", I know, but logically that is a boolean in quite many ways.

Edit: markup asterisk failure.

▲ tialaramex 2 days ago | parent | next [-]

One reason people think success == true is a good idea is they are (as in C) working with truthiness.

In C "false" is truthy, and so is "" but 0 is falsy

In a language where types aren't a gentle suggestion "false" is a string, so it can't be true or false, which are booleans. In such a language if (success) implies that success is a boolean, so the comparison is redundant. But C is not that language.

▲ kmoser 2 days ago | parent | prev [-]

> if (success = true) // Oops!

Hence the better way of comparing literals or consts to vars:

  if ( true = success ) // Compile-time error will enlighten you

	▲	brontitall 2 days ago \| parent [-]
		https://en.wikipedia.org/wiki/Yoda_conditions

▲ 0xTJ 2 days ago | parent | prev | next [-]

I agree strongly with almost everything presented in Notes on Programming Practices. The only thing I would consider to be bad advice is how booleans are handled, and that's just because this is from before C99 and stdbool.

I've seen enough "modern legacy" code with custom boolean macros defined to resent that on sight, so it stood out, even knowing this is advice from the time it was written.

▲ Waraqa 2 days ago | parent | prev | next [-]

The page style doesn't look so bad even though it's using very simple HTML elements of the era. Just looking at it reminded me of the early days of HTML.

edit: It uses CSS which was invented in 1996 (according to Wikipedia). That means it was updated at a later date.

▲ mwkaufma 2 days ago | parent | prev | next [-]

The only time-tested rule for good style is "consistent with your colleagues and dependencies."

▲ z_open 2 days ago | parent | prev [-]

Lots of bad advice. Using unsigned for normal integers when you know they will be positive does worse for optimization, not better. Also for (;;) {} is convention because older compilers would give warnings with while (1)

I stopped reading there.