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

181–190 of 466 posts

Re: My personal C coding style as of late 2023

#181

Post by jll29 »

The notion of "personal style" is problematic, even for hobby projects, because (good) programming is ultimately a social activity.

Even Linux started as a personal project, but because of its quality and the need it met it quickly spread. So please write your code in such a way that experienced other C programmers can read it easily.

In isolation, I like some of his ideas, but some issues with C remain, and he is perhaps just to comfortable with C to jump ship and embrace Rust, which has many things he likes and more (e.g. no buffer overflows by design).

Re: My personal C coding style as of late 2023

#183

Post by da39a3ee »

> #define countof(a) (sizeof(a) / sizeof(*(a)))

> #define lengthof(s) (countof(s) - 1)

It makes no sense to use the word "length" to mean one less than the number of items. You could call it maxindexof perhaps.

There may be good arguments for zero based indexing, but we have to also accept that there are downsides. One is that your code has to feature an artificial quantity obtained by subtracting one from a meaningful quantity.

Re: My personal C coding style as of late 2023

#184

Post by circuit10 »

oaiey wrote: post #142
colejhudson wrote: post #91

Earlier quoted context omitted.

I mean, being a bit glib here, but a lot of programming is dealing with someone else's type system. Moreover, for those of us who write C fairly often, the mnemonics here are familiar. Actually, as custom type systems go, this one is pretty elegant. Reminds me of Rust.

Yeah but not for basic types. Also, most code mingles sooner or later with other code. Than this is just ugly.

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

Re: My personal C coding style as of late 2023

#185

Post by mariusor »

MilanTodorovic wrote: post #148
billforsternz wrote: post #115

Earlier quoted context omitted.

This is all very good and very, ahem, true. But (and it's a big butt); if (need_free == true) Is such a horrible code smell to me. You have a perfectly good boolean. Why compare it to a second boolean to get a third boolean? if (need_free) or if (!need_free) for the opposite case is so much better. I will admit that in my world this leaves if (need_free == some_other_bool) as something I don't have a particularly com…

Couldn't we do it like (!need_free == !some_other_bool)?

You can go the php way and do if (!!need_free)

Re: My personal C coding style as of late 2023

#186

Post by Nursie »

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…

> These types should be defined in the right header

stdint.h

It's always been amazing to me how many different projects I've worked on (not that I've been in professional C for about 7 years now)) that include their own painstaking recreation of this file.

Reusing them and effectively translating them just to your own name is just annoying to the reader IMHO. I am reminded of a C++ project I worked on, where I questioned the extensive use of typedefs around collections of things, various forms of references and compound objects etc. I was informed by one of the more experienced C++ folks that it made the code easier to comprehend.

Later I saw the typedef cheat-sheet sellotaped to the side of his monitor...

Re: My personal C coding style as of late 2023

#187

Post by otikik »

lelanthran wrote: post #173
otikik wrote: post #165

Earlier quoted context omitted.

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…

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.

Re: My personal C coding style as of late 2023

#188

Post by runiq »

iforgotpassword wrote: post #172
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.

Because we've used those names since forever, but that's archaic random crap really. Nothing apart from maybe "byte" makes sense here, the rest is completely arbitrary historic cruft. Could as well have called the rest timmy, britney and hulk.

> Nothing apart from maybe "byte" makes sense here

Lest we forget: https://web.archive.org/web/20170403130829/http://www.bobbem...

Re: My personal C coding style as of late 2023

#189

Post by another2another »

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.

In that case D should probably start to have an internal conversation about what they're going to call 128 bits then, 'cause its going to become a thing sooner or later.

stdint already has that covered though: (u)int128_t

Re: My personal C coding style as of late 2023

#190

Post by Communitivity »

lelanthran wrote: post #173
otikik wrote: post #165

Earlier quoted context omitted.

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…

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