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

301–310 of 466 posts

Re: My personal C coding style as of late 2023

#301

Post by beeforpork »

Hopefully I never need to review code written with these definitions. It's an awful idea to do this.

The first section shows why some languages have no 'typedef': introducing another layer of aliases is just not a good idea. It's confusing, it changes the appearance to basically a new language. Just use the standard names, instead of redefining your language, like everyone else. This style is almost as bad as '#define begin {'.

Many of the other defs are obfuscations or language changes -- this coerces C to something else. I'd not like to read code written with this, as it heavily violates the principle of least astonishment (POLA).

(As a side note, I don't understand the #define for sizeof. The operator sizeof returns size_t -- it's size_t's definition, so what is this for?)

Re: My personal C coding style as of late 2023

#302

Post by avgcorrection »

barbs wrote: post #297
avgcorrection wrote: post #227

Earlier quoted context omitted.

Thanks for bringing this up. There is no reason for modern languages that have proper constants (not preprocessor macros which happen to sometimes be used for them) to use this tedious style. Constants are so innocent and useful. Why indirectly discourage their use by making their usage an eye-bleed?

What alternative would you suggest?

Writing in a normal way in snake case or camel case or whatever the convention is.

Re: My personal C coding style as of late 2023

#303

Post by circuit10 »

uxp8u61q wrote: post #295
circuit10 wrote: post #184

Earlier quoted context omitted.

It’s better than dealing with needlessly long type names like uint32_t though

Long type name?? uint32_t is literally 8 characters long. There's not much to cut here.

It’s longer than it needs to be when you’re typing it out so many times

Re: My personal C coding style as of late 2023

#304

Post by seanw444 »

WalterBright wrote: post #164
guidoism wrote: post #97

Earlier quoted context omitted.

I agree. A lot of languages have settled on those same names or something similar. We don’t live in a world with a single word size anymore so carrying bit length in the name is critical, and so is keeping identifier names short. His trade off is exactly the one I would make.

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

Re: My personal C coding style as of late 2023

#305

Post by circuit10 »

oaiey wrote: post #283
circuit10 wrote: post #184

Earlier quoted context omitted.

It’s better than dealing with needlessly long type names like uint32_t though

No. It would be better if the standardization groups would have done that, but not when every developer has a different scheme

It’s not great but they’re just aliases so they’re interchangeable, which means you can keep everything consistent within a project and it won’t cause any problems when interacting with outside code

Re: My personal C coding style as of late 2023

#306

Post by grotorea »

self_awareness wrote: post #239
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…

Isn't "int" 64-bit on some (rare) architectures?

Not mentioned on the table I know https://en.cppreference.com/w/cpp/language/types

edit: Oh you're right

> Other models are very rare. For example, ILP64 (8/8/8: int, long, and pointer are 64-bit) only appeared in some early 64-bit Unix systems (e.g. UNICOS on Cray).

Re: My personal C coding style as of late 2023

#307

Post by slikrick »

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…

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 correct by labeling the bits with the type directly

Re: My personal C coding style as of late 2023

#308

Post by [deleted] »

jstimpfle wrote: post #202
outsomnia wrote: post #140

Earlier quoted context omitted.

It wasn't clear to me if he's talking about const as a variable declaration qualifier - I never used it - or const in pointer types, which is very useful.

For me it's the other way around -- I use const for global variables because it makes a real difference, the data will be put in a .ro section. Pointer-to-const on the other hand (as in "const Foo *x") is a bit of a fluff and it spreads like cancer. I agree with the author that const is a waste of time. And it breaks in situations like showcased by strstr() . I use pointer-to-const in function parameter lists though…

[deleted]

Re: My personal C coding style as of late 2023

#309

Post by slikrick »

uxp8u61q wrote: post #295
circuit10 wrote: post #184

Earlier quoted context omitted.

It’s better than dealing with needlessly long type names like uint32_t though

Long type name?? uint32_t is literally 8 characters long. There's not much to cut here.

if you like typing _, go ahead, but it's not 1 key press and shouldn't be treated as a keystroke like the letter a...
Post reply on HN