Re:Principles for C programming
by simias on Thursday March 16, 2017 @05:13AM
(#13883601)
I used to typedef my structs but I stopped doing that a while ago. Even if something is an opaque type it's still useful to know that it's a struct and not some random typedef for an integer or similar. You might not be able to copy it for instance, and if you can you might not want it if it turns out to be a few kilobytes in size and harms performance.
I don't agree with everything in the kernel coding style but it's mostly reasonable and I think their approach to typedefs is perfectly reasonable.
And why do you use separate typedefs for pointer types? That's borderline obfuscation IMO, if I'm dealing with a pointer I want to know it. If it's in order to save a single keystroke it really isn't worth it IMO and I don't see how it helps reworking anything.
I agree with the fixed size buffer thing though. There are plenty of situations where fixed size buffers are completely fine, that's way too broad as a general "principle". I guess the idea is "make sure you don't reserve less memory than you need" but that's rather obvious, isn't it?
The linux kernel coding style in particular forbids such typedefs: https://www.kernel.org/doc/html/latest/process/coding-style....
I don't agree with everything in the kernel coding style but it's mostly reasonable and I think their approach to typedefs is perfectly reasonable.
And why do you use separate typedefs for pointer types? That's borderline obfuscation IMO, if I'm dealing with a pointer I want to know it. If it's in order to save a single keystroke it really isn't worth it IMO and I don't see how it helps reworking anything.
I agree with the fixed size buffer thing though. There are plenty of situations where fixed size buffers are completely fine, that's way too broad as a general "principle". I guess the idea is "make sure you don't reserve less memory than you need" but that's rather obvious, isn't it?