[loondri]

I get that everyone has their own coding style, but ditching established conventions in C for personal aesthetic seems a bit much. Like, using u8 or i32 instead of the standard uint8_t or int32_t might save a few keystrokes, but it could confuse anyone else looking at the code. And the custom string type over null-terminated strings? C's built around those, and deviating from that just feels like making life harder for anyone else who might need to work with your code.

And manually writing out Win32 API prototypes instead of including windows.h might shave off some compile time, but it's like ignoring a well-maintained highway to trek through the woods. Just seems like a lot of these changes are about personal preference rather than sticking to what makes C code easy for everyone to work with.

[SkeuomorphicBee]

> Like, using u8 or i32 instead of the standard uint8_t or int32_t might save a few keystrokes [...]

It is not about saving keystrokes, it is about reducing sensory load when reading it.

Sorry, I know it may sound like I'm splitting hairs, but every single time when the argument of verbosity vs conciseness in programing languages comes around, this "keystrokes" argument is thrown and it is extremely flawed. The core belief that conciseness is only better for faster typing but that verbosity is somehow always better than conciseness for reading is just plain wrong and we should stop using it. And yes, verbosity has some advantages for reading comprehension, but so does conciseness, no side is a clear winner, it is all about the different compromises.

[__loam]

I think you completely missed the point of his comment. C isn't a new programming language. There are well worn conventions and making custom types because you don't like them is like forking your own custom dialect nobody can understand for very little benefit.

[tuatoru]

No experienced C programmer is going to misunderstand u8 in a declaration.

[JonChesterfield]

u16 etc show up a lot and are unlikely to confuse programmers.

Where it does go to pieces is when two different programs both define u16, use them in header files, and then a third program tries to include both those header files at the same time. The big advantage of <stdint.h> is avoiding that failure mode.

The namespaced library type equivalent is something like libname_u32, at which point it's tempting to write uint32_t instead of the libname:: or libname_ prefix.

[michaelcampbell]

> Like, using u8 or i32 instead of the standard uint8_t or int32_t might save a few keystrokes, but it could confuse anyone else looking at the code.

This seems a theoretical possibility _at best_, and a fairly strawman-y one at that. I doubt any competent C programmer would get "confused". Irritated at a different style, maybe.

Too, everything is hard to read before you learn to read it. -- Rich Hickey