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

81–90 of 466 posts

Re: My personal C coding style as of late 2023

#81

Post by david2ndaccount »

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 actual enforcement around them and due to aliasing the compiler generally can’t assume the parameter doesn’t actually change anyway.

Re: My personal C coding style as of late 2023

#82

Post by thefourthchime »

tom_ wrote: post #41
bsder wrote: post #29

> signed sizes are the way Well, I should probably just say "We're done here." and stop reading the rest of the article. "Signed sizes" are an extremely surprising abstraction break that are just asking for disaster. > No const. It serves no practical role in optimization, and I cannot recall an instance where it caught, or would have caught, a mistake. Should you even be writing C if you haven't hit this? People mix…

The no-const people will never be satisfied, so just use const as necessary, propagate as required, and ignore them when they complain. If they take it out, put it back in. They'll always get bored first. I've been doing this for 25 years, and I'm still here. (The static thing might depend on the tooling. I went static-by-default about 15 years ago, around the same time I went full size_t, and I've yet to have a prob…

I’ve been her 30 years. I’ve never found much use for const. I value brief simple code that doesn’t rely on things like const to tell people what’s going on.

Codebases have their own conventions and design patterns. If you have that const is a needless formality.

Code should be being simple and clean first, constantly stating things that are obvious 90% of the time isn’t that.

Re: My personal C coding style as of late 2023

#83

Post by [deleted] »

thetic wrote: post #43

> #define sizeof(x) (size)sizeof(x) Undefined behavior[1] > #define assert(c) while (!(c)) __builtin_unreachable() Undefined behavior[1] > I’ll cast away the const if needed. Undefined behavior[2] > The assignments are separated by sequence points, giving them an explicit order. I don't believe assignments are sequence points and only the function call is. [1] https://en.cppreference.com/w/c/language/identifier#Reser…

[deleted]

Re: My personal C coding style as of late 2023

#84

Post by Uptrenda »

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 it depends on compiler?) It's been a while since I wrote any amount of C so my apologizes if this isn't correct.

Re: My personal C coding style as of late 2023

#85

Post by glitchc »

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…

I'm afraid you are mistaken. In particular for pointers, const does not guarantee that the memory at the location pointed to won't change. Const only guarantees that the address itself doesn't change.

Re: My personal C coding style as of late 2023

#86

Post by voxl »

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

Re: My personal C coding style as of late 2023

#87

Post by ComputerGuru »

badsectoracula wrote: post #52
ComputerGuru wrote: post #31

I might just be a grumpy old dev but a lot of this stuff gets an immediate no from me because it’s so unidiomatic. You have to unlearn the accepted way of doing things and you end up with a codebase that is just so foreign to anyone looking at even a small chunk of it, unless they are committed to really learning to do things your way. Everyone knows what a uint32_t is when they see it. The cognitive overhead (until…

> I might just be a grumpy old dev [...] Everyone knows what a uint32_t is when they see it. You might not be old enough then :-P many codebases typedef their own int types. See glib (gint, gshort, gint32, etc), SDL (Sint32, Uint32, etc) off the top of my head and there are many that define types like "int32" or "i32" like the linked article.

I cut my teeth on DWORD, PHALF_PTR, and friends, so my issue is not so much “don’t know how to grok this” as it is “we finally have sane, universal type names and you’re throwing them away.”

Sure, the _t suffix may be an eyesore but I’ll take size_t over “size” any day.

Re: My personal C coding style as of late 2023

#88

Post by xvedejas »

stefan_ wrote: post #63
xvedejas wrote: post #27

Earlier quoted context omitted.

This is the use case for `uint_fast8_t` (part of the C99 standard); it should use whatever width of unsigned integer is enough to store a byte, but fastest for the platform. You always know that the type can be serialized as 8 bits, but it might be larger in memory. So long as you don't assume too much about your struct sizes across platforms, it should be a good choice for this. Although, if alignment is an issue, i…

10 years ago when ATmegas were still around and your 32 bit variable was generating 3 instructions for addition I would say „right on“ but now everything is a 32 bit Cortex-M and please stop polluting your code with this nonsense

Please understand, I am still in a position where I am writing new code for a platform which only has one compiler, a proprietary fork of GCC from nearly 20 years ago. I assume other C programmers might have similar situations.

Re: My personal C coding style as of late 2023

#89

Post by ComputerGuru »

mberning wrote: post #42
ComputerGuru wrote: post #31

I might just be a grumpy old dev but a lot of this stuff gets an immediate no from me because it’s so unidiomatic. You have to unlearn the accepted way of doing things and you end up with a codebase that is just so foreign to anyone looking at even a small chunk of it, unless they are committed to really learning to do things your way. Everyone knows what a uint32_t is when they see it. The cognitive overhead (until…

To be fair they did say that when contributing to a shared project they follow the prevailing standard. I don’t see the harm in following this for your own passion projects. You aren’t doing it for the world, you’re doing it for yourself.

I mean to each their own, but in my own experience, I value being able to easily and reliably copy-and-paste code snippets across projects (and I have a million of them, across several evolutions of my own personal coding styles and conventions) or files without worrying about whether the typedefs are in scope, polluting a namespace with possibly conflicting names or macros, etc.

I also have often found myself publishing “for my own use only” code as open source later and like to keep things understandable to maybe help teach someone something someday.

Re: My personal C coding style as of late 2023

#90

Post by kibibu »

glitchc wrote: post #85
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…

I'm afraid you are mistaken. In particular for pointers, const does not guarantee that the memory at the location pointed to won't change. Const only guarantees that the address itself doesn't change.

Should perhaps be

    int Foo_bar(const Foo * self);
Post reply on HN