Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My personal C coding style as of late 2023

nullprogram.com

Post reply on HN
Print view View original

331–340 of 466 posts

Re: My personal C coding style as of late 2023

#331

Post by lelanthran »

slikrick wrote: post #307
WalterBright wrote: post #163

Earlier quoted context omitted.

The reality is that C `int` is 32 bits in size. Sure, that's not true for 16 bit targets. But are you really going to port a 5Mb program to 16 bits? It's not worth worrying about. Your code is highly unlikely to be portable to 16 bits anyway. The problem is with `long`, which is 32 bits on some machines and 64 bits on others. This is just madness. Fortunately, `long long` is always 64 bits, so it makes sense to just…

so... what I'm seeing is that C got it wrong relative to the way things actually work and get used. the fact that you had to have tribal knowledge about all of this is why C shouldn't stay for the long term and we should phase out languages into ones with stronger more correct defaults. would a new programmer use "long long"? would they notice immediately that things didn't work if they didn't use it? Rust got it cor…

You realise that C had labeled types long before Rust was conceived?

Re: My personal C coding style as of late 2023

#332

Post by avgcorrection »

_moof wrote: post #326
yakubin wrote: post #314

Earlier quoted context omitted.

In C++ I do it Google style: static constexpr int kConstantName = 42;

This is the old Mac style too. Might just be my upbringing but I prefer it.

What's the point of the `k` prefix?

Re: My personal C coding style as of late 2023

#333

Post by SkeuomorphicBee »

loondri wrote: post #242

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 f…

> 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.

Re: My personal C coding style as of late 2023

#336

Post by adamrezich »

neilv wrote: post #216

> While I still prefer ALL_CAPS for constants, I’ve adopted lowercase for function-like macros because it’s nicer to read. "ALL_CAPS" in C was not for constants, but for preprocessor macros. It's shouting in all-caps, because it means "Look out! There's a cpp macro expansion here!" Related, please stop using "ALL_CAPS" for constants in other languages. Not only does shouting constants as the most prominent syntax in…

nah, sorry, I'm going to keep using ALL_CAPS_CONSTANTS (and enum members, because they're also constants). I like having constants be visually distinct from the rest of my code.

Re: My personal C coding style as of late 2023

#339

Post by ogogmad »

seanw444 wrote: post #304
WalterBright wrote: post #164

Earlier quoted context omitted.

> carrying bit length in the name is critical I beg to disagree. In D: byte - 8 bits short - 16 bits int - 32 bits long - 64 bits absolutely nobody is confused about this.

When we move into the 128-bit CPU era, will we call 128-bit integers "super long"? Maybe "elongated". Maybe "huge"? Or, you know, we could just name them all by bit length and completely future-proof this system.

Why would we ever need 128-bit CPUs? I remember the PS2 had something like that (with details and caveats I don't understand), but subsequent games consoles went back to a more usual register size: https://en.wikipedia.org/wiki/128-bit_computing

Re: My personal C coding style as of late 2023

#340

Post by sovande »

WalterBright wrote: post #163
Uptrenda wrote: post #84

IMO, defining your own types is one step too far. Now everyone who is already familiar with C types has to learn your own quirky system to understand one program. I think it does probably make sense to be specific about the sizes though e.g. using uint32_t over just uint (and expecting to receive some architecture-dependent size you might not get with uint.) These types should be defined in the right header (I think…

The reality is that C `int` is 32 bits in size. Sure, that's not true for 16 bit targets. But are you really going to port a 5Mb program to 16 bits? It's not worth worrying about. Your code is highly unlikely to be portable to 16 bits anyway. The problem is with `long`, which is 32 bits on some machines and 64 bits on others. This is just madness. Fortunately, `long long` is always 64 bits, so it makes sense to just…

Exactly this (plus floating point types and unsigned qualifier) and done. It’s standard C, there is no need to invent yet another unnecessary “type” system for standard C native types. I do like bool though.
Post reply on HN