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

171–180 of 466 posts

Re: My personal C coding style as of late 2023

#171

Post by asalahli »

wiseowise wrote: post #155
outsomnia wrote: post #139

Earlier quoted context omitted.

In isolation, they're not crazy. But much C code is bringing in library headers which contain their author's own pet choices for these, which inevitably are not the same and the result is extremely confusing when you have that in play as well as the stdint.h ones. The kernel contains a mixture of "pet" types like u32 and stdint ones, it's already confusing. He also does make a "crazy" choice later to call his string…

> which clashes with his nomenclature here. How?

Because it can be mistaken for 8-bit signed integer.

Re: My personal C coding style as of late 2023

#172

Post by iforgotpassword »

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.

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.

Re: My personal C coding style as of late 2023

#173

Post by lelanthran »

otikik wrote: post #165
lelanthran wrote: post #159

Earlier quoted context omitted.

> 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, whi…

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.

Re: My personal C coding style as of late 2023

#174

Post by marwis »

rkagerer wrote: post #149
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 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.

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

Re: My personal C coding style as of late 2023

#175

Post by consp »

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…

Which are minima, but in practice they represent the width.

Re: My personal C coding style as of late 2023

#176

Post by PennRobotics »

jenadine wrote: post #135
kibibu wrote: post #90

Earlier quoted context omitted.

Should perhaps be int Foo_bar(const Foo * self);

`const Foo*` and `Foo const*` are exactly the same and just a question of style (east-const vs. west-const) Not to be confused with `Foo *const`

For anyone thinking, "wtf const pointer order??" fall back on the spiral rule:

https://c-faq.com/decl/spiral.anderson.html

Re: My personal C coding style as of late 2023

#177

Post by staunton »

david2ndaccount wrote: post #2

I disagree about the structs vs out-parameters thing. I’ve found it makes functions that could return an error much harder to compose and leads to a proliferation of types all over the place. In practice almost all functions can fail (assuming you are handling OOM), so having a predictable style of returning errors is more important.

> assuming you are handling OOM

Which almost noone ever does. It's very hard and almost never has any benefit. At that point you have way different problems than programming style choices...

Re: My personal C coding style as of late 2023

#178

Post by quelsolaar »

You can declare flexible array member strings with literals like this:

#define DECLARE_STRING(variable_name, string) struct{size_t allocated; size_t used; char string[sizeof(c_string)];} variable_name ## internal = {.allocated = sizeof(c_string) - 1, .used = sizeof(c_string) - 1, .string = c_string}; MyString *variable_name = &variable_name ## internal

Its a lot of C99 magic, so it may not be what you want but it is possible.

Re: My personal C coding style as of late 2023

#179

Post by wyldfire »

zombot wrote: post #152
kristopolous wrote: post #128

Earlier quoted context omitted.

Speaking of type systems, I read glib as g-lib a few times and tried to understand how you were talking about the GNU lib in that sentence.

Wouldn't that have to be `glibc`?

It is unfortunate that the two have such similar names because there's a lot of room for confusion. It doesn't help that they have somewhat adjacent functionality almost.

Re: My personal C coding style as of late 2023

#180

Post by _old_dude_ »

flakes wrote: post #156
skovati wrote: post #122

Earlier quoted context omitted.

FWIW, Java does have the "final" keyword.

Final only protects the variable from being assigned a new reference (similar to a const pointer). It doesn’t protect any of the underlying data held by the object from being changed, unless the entire hierarchy has every field declared final as well. I still use final heavily in all of my Java code, but it doesnt convey the full intent I would like it to.

I remember James Gosling saying, a long time ago, that the whole class should be either mutable or not so you do not need to tag some methods with const.

The consequence is that you may define two classes, one non-mutable and one mutable like String/StringBuilder.

Post reply on HN