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

161–170 of 466 posts

Re: My personal C coding style as of late 2023

#161

Post by lelanthran »

voxl wrote: post #86
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…

they're not quirky types in the least...

> they're not quirky types in the least...

But they are buggy (correct code cannot depend on the sign of `char`), which is usually the result of typedefing primitive types to save typing 3 characters on each use.

Re: My personal C coding style as of late 2023

#162

Post by slondr »

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`?

https://en.wikipedia.org/wiki/GLib?wprov=sfti1

Re: My personal C coding style as of late 2023

#163

Post by WalterBright »

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 abandon `long`.

So there it is:

    char - 8 bits
    short - 16 bits
    int - 32 bits
    long long - 64 bits
Done!

(Sheesh, all the endless hours wasted on the size of an `int` in C.)

Re: My personal C coding style as of late 2023

#164

Post by WalterBright »

guidoism wrote: post #97
voxl wrote: post #86

Earlier quoted context omitted.

they're not quirky types in the least...

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.

Re: My personal C coding style as of late 2023

#165

Post by otikik »

lelanthran wrote: post #159
rkagerer wrote: post #149

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.

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

Re: My personal C coding style as of late 2023

#166

Post by zeroCalories »

I think C really needs an update to the standard library that includes these shorter types. Seems like a fine list though.

Some of my own style changes this year:

I try really hard to write functional code. Mainly try to keep functions pure, and write declarative code. I find that this makes the code easier to write(not necessarily read), and I'm less scared of bugs.

I also avoid malloc unless I absolutely need it. You can usually preallocate space on the stack or use a fixed length buffer, which pretty much avoids all fears of memory leaks or use after free type bugs. You will sometimes waste memory by allocating more than you need, but it's a lot more predictable.

Re: My personal C coding style as of late 2023

#167

Post by lelanthran »

jpcfl wrote: post #71
hyc_symas wrote: post #32

typedef all structs - yes, helps with conciseness. Use typedefs liberally, I say. But only typedef the things themselves, not pointers to the things. You can always use (type *) when you need a pointer. In particular, for function pointers, typedef the function, not the function pointer. Then you can use the function typedef for function declarations too, which gives you parameter type checking without needing to fix…

I prefer to use typedef's for opaque structs to emulate classes with all private fields, and use 'struct' for plain ol' data structures. Classes should only be accessed via functions, while structs can be accessed directly. I think this is more-or-less a C/POSIX standard convention. E.g., `pthread_t` vs. `struct stat`.

> I prefer to use typedef's for opaque structs to emulate classes with all private fields, and use 'struct' for plain ol' data structures. Classes should only be accessed via functions, while structs can be accessed directly.

Totally agree, I even wrote this as a blog post: https://www.lelanthran.com/chap9/content.html

Re: My personal C coding style as of late 2023

#168

Post by lelanthran »

david2ndaccount wrote: post #81
jpcfl wrote: post #78

Parameters and functions No const. Please don't. `const` is incredibly valuable, not only to the reader, but to the compiler. Take for example: int Foo_bar(Foo const* self); Just looking at this signature, I know that calling `bar()` will not modify the state of the object. This is incredibly valuable information to the reader. Furthermore, if I want to create a `Foo` constant, I can only call this function if it is…

You only know there are no mutations if Foo itself does not contain any indirections. Additionally, the compiler generally cannot assume that Foo_bar does not modify Foo as it is legal to cast away const as long as it is not originally a variable declared as const (so in your static Foo example it would be UB to cast away const). static + const is valuable, but const parameters are merely a convention, there is no ac…

> Additionally, the compiler generally cannot assume that Foo_bar does not modify Foo as it is legal to cast away const

No, but it can warn you!

The type is meant to capture programmer intention, and if you use `const` the compiler can warn you that your intention does not match the intention of the existing code (like, the intention of the author who wrote Foo_Bar).

Re: My personal C coding style as of late 2023

#169

Post by iforgotpassword »

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.

That ship has sailed ages ago. There are some things you should just accept about C, or any programming language really. Just because you can do something doesn't mean you should do something. I don't know how many years of experience in C this guy has, but this is a "been there, done that" case for me. I stick to stdint and stdbool today, and even if only half the code/libs I interface with do that, it's already worth the extra _t-typing all the time. Just the fact that they use the i prefix for signed, and s for string has a high chance that his s8 string type gets confused with an 8-bit signed int.

But as you say, it's a personal style, and the author seems to be aware of that:

> I’m not saying everyone should write C this way, and when I contribute code to a project I follow their local style.

Because that's by far the most important rule to follow in any language.

I think the rest is less controversial, the 0 vs. NULL thing has been going on forever; I didn't check recently but I'd assume "const somestruct *foo" would still sometimes help out the compiler to optimize vs. the non-const version.

Re: My personal C coding style as of late 2023

#170

Post by iforgotpassword »

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.

Because those existing programs surely don't use the same identifiers for other stuff? Certainly there is no code out there using s8 for "signed char" instead of "utf8 string"? :-)
Post reply on HN