> The author did qualify it with personal coding style. Frankly the standard types are too verbose and I wish this guy's elegant and clear list had been the one that was adopted way back when.

They didn't adopt it for the same reason that it is a bad idea now - too many programs already contained at least one variable named after his types.

If the standard had adopted his convention, too many programs will break, which is why his convention is currently unsuitable for any existing project.

Wouldn’t existing programs just continue working? What the author did was adding new types, not modifying or removing existing ones.

> Wouldn’t existing programs just continue working?

Only ones which don't have variables named `i8` or `b32` (which is common, but not for booleans).

I've seen many projects which used the pattern [a-z][1-9]+ as variables. Those programs with a variable called `i8` won't compile if the standard made a type called `i8`.

In particular, the standard reserves entire patterns to itself, so it cannot reserve the pattern of [a-z][0-9]+. They could, and did, reserve the pattern *int*_t for themselves.

But that problem exists for any C project that uses an external library. If the library defines something that the project already uses, then the project will not work.

In my mind that's not a problem with the decisions taken by the author of the article, it's more of a symptom of C's limitations.

> But that problem exists for any C project that uses an external library. If the library defines something that the project already uses, then the project will not work.

For libraries, yes, but we're talking about why the standard didn't do it.

The standard did not want[1] to reserve keywords that current programs were already using.

A library that conflicts on keywords will only break with those programs that use it. A standard that conflicts on keywords breaks all programs in that language.

> In my mind that's not a problem with the decisions taken by the author of the article, it's more of a symptom of C's limitations.

One of the constraints of taking decisions is to work within the limits existing framework - if you're avoiding the alternatives that don't break, then it's the decision-makers bug, not the frameworks.

The framework has limitations, widely published and known. You make decisions within those limitations.

[1] Although, they do do it, it's only with relectance, not on a whim to avoid typing a few characters)

No program should every have variables names according to [a-z][1-9]+ pattern, except perhaps loop indices - and not even then.

> No program should every have variables names according to [a-z][1-9]+ pattern, except perhaps loop indices - and not even then.

What's that got to do with not breaking existing programs?

Those may be terrible variable names but they were understandable back in the 70s and 80s when disk space was at a premium and compilers only cared about the first 6 characters in a variable or function name. That's the downside of a 50 or so year old programming language: you have to worry about not breaking legacy code that did things based on the hardware limitations of that time.

Typedefs and variable namens don't live in them same namespace, do they?

> Typedefs and variable namens don't live in them same namespace, do they?

Depends. See this snippet: https://www.godbolt.org/z/5T5jz47q4

Cannot declare a variable called `u8` when there is a typedef of `u8`.

And even when you can declare a variable called (for example) `int`, that effectively "breaks" the program by not being even a tiny bit readable anymore.

Because those existing programs surely don't use the same identifiers for other stuff? Certainly there is no code out there using s8 for "signed char" instead of "utf8 string"? :-)

That ship has sailed ages ago. There are some things you should just accept about C, or any programming language really. Just because you can do something doesn't mean you should do something. I don't know how many years of experience in C this guy has, but this is a "been there, done that" case for me. I stick to stdint and stdbool today, and even if only half the code/libs I interface with do that, it's already worth the extra _t-typing all the time. Just the fact that they use the i prefix for signed, and s for string has a high chance that his s8 string type gets confused with an 8-bit signed int.

But as you say, it's a personal style, and the author seems to be aware of that:

> I’m not saying everyone should write C this way, and when I contribute code to a project I follow their local style.

Because that's by far the most important rule to follow in any language.

I think the rest is less controversial, the 0 vs. NULL thing has been going on forever; I didn't check recently but I'd assume "const somestruct *foo" would still sometimes help out the compiler to optimize vs. the non-const version.

I use very similar types as the author in my own libs and framework.

I think this is perfectly legitimate, in the same way that I don't use std libs directly but always behind wrappers or my own implementation.

The C std lib and default types are often what is keeping the language back.

And they should be used when you have no other choice.

Short name for scalar types is also pretty much the new standard for modern languages such as Zig.

In case of winapi you can actually generate your own headers following the style you want, see for example https://github.com/microsoft/cppwin32