> While 'bool' is valid C99 code, it is more or less never used in C code.

I disagree. It's used quite a bit in the code I work on. Little things like an explicit statement that this variable is only true or false significantly reduce the cognitive load when reading code.

Anyway, even if it were true that nobody uses bool, there's absolutely no reason to discourage its use.

> Little things like an explicit statement that this variable is only true or false significantly reduce the cognitive load when reading code.

Since it's allowed to use bool in arithmetic context (some_int + some_bool will compile fine, for example), having a bool type is useless. (Useless in C and C++ that is; Java, for example, has sane bool handling.)

I have no idea why C99 introduced _Bool type when they could have just inserted typedef char bool; in stdbool.h. Has anybody ever used for something useful the fact that memory representation of _Bool is constrained to read as 0 or 1?

1. It's semantically valuable, or you wouldn't see it defined in everyone's code

2. C lets you commit all kinds of atrocities in arithmetic contexts with or without it.

3. Having a standard typedef saves us from all having to make our own

4. None of your points support the case of "don't use stdbool"

> 4. None of your points support the case of "don't use stdbool"

Huh? I was saying that the language did not have to be extended to get a bool typedef. C99 defines a new type, _Bool (name from the reserved identifier space), which is different from existing types. stdbool is a simple typedef of _Bool to bool.

Also, introducing bool would have had meaning if implicit conversion to int wasn't allowed. But since it is, it's a useless type.

My viewpoint is that types exist for enforcing semantic constraints; what use of a bool type that allows performing semantically nonsense operation, such as implicit conversion to int in arithmetic context? The C99 committee messed it up big with bool.

Adding it to the language saves us all the work of typedefing it. Which is a very common practice.

C's approach to typing is, in general, pretty weak. Mostly they're there so the compiler can decide how much space to set aside. There's no point singling out this particular instance of nonsense when everywhere you turn in C you're greeted by other forms of the same nonsense. There's no point being pedantic about bool if you're not going to be pedantic about all the other types.

Enough bikeshedding. Use it or don't.

> There's no point singling out this particular instance of nonsense when everywhere you turn in C you're greeted by other forms of the same nonsense.

By your reasoning, since nonsense already exists, it's pointless to try to do the right thing. And they could have done it.

Presumably some optimiser could use this fact to pack several bools into the same register?

it still is a useful annotation

I'm aware of no "older systems" still in reasonable use that don't support the // comment convention. That got added to pretty much every C toolchain as soon as anyone started shipping a C++ preprocessor. I believe it is disabled by the -ansi switch to gcc though; use -std=c99 instead if you care about that stuff (or better: don't use -ansi, it doesn't actually make your code more portable, it just whines a lot).

(3) You bring up an interesting issue. Why is there so much variance out there? Google uses 2 spaces, the linux kernel uses 8, and most people I know use 4.

Are people using such a wide range of font sizes, and font aspect ratios, that 4 spaces doesn't make sense for everyone?

I used 3 on my last open source C project, just to troll every faction of the indent war. I actually think it looks pretty nice.

https://raw.github.com/udp/json-parser/master/json.c

indent -kr json.c

problem solved ;-)

When I was writing a lot of C, I settled on 8-column tabs (a style I copied from OpenBSD). Combined with an 80-column wide terminal, it prevents you from nesting too far down — 4 or 5 levels and you keep having to wrap, which is an automatic sign that "something is wrong, I need to refactor this."

I was an 8spcr (default tabstop, tab-to-indent, learned C in pico). I've gone a year or two writing nothing but Ruby (where 2spc is the rule) and recently had to build a small C program, and oh my god is 8spc terrible.

But I'm also a single-return fetishist, so I tend to nest deeper than normal.

It's funny how so many coders take offence at such trivial things. I always get annoyed by cuddled elses, although I don't suppose I could give a rational explanation for this!

I also feel annoyed by cuddled elses. My reason (rationalization?) is that because the else clause is visually further indented it seems to suggest that the clause is somehow less important, and it's also harder to see the structure of the code when the if and else don't align.