Honest question: why C? I've been writing C++ firmware for SoCs, supposedly an area where C is supposed to be king, and C++ was just as good, except it came with all the batteries included. So, why C?
My personal C coding style as of late 2023
271–280 of 466 posts
Re: My personal C coding style as of late 2023
#272> No const. I stopped reading there. I wish this guy a happy coding (and non-coding) life, but I hope we never work together.
I'd love to have him in a team. He truly cares exactly how code works and analyzes/fuzzes the hell out of everything. I don't agree with all stylistic choices in his code, but the level of experience and skills are far above most C developers.
"Skills" are subjective, but significant "experience" would involve traumatic foot-shooting turning him off most of the things advocated in this post.
Re: My personal C coding style as of late 2023
#273Earlier quoted context omitted.
Fun read. What happened to the conditional expressions? Move them to the interiors of doX() and doZ(). That was an interesting point. Not sure that it's always valid but I guess it depends where you want the abstraction to lay, and how it affects the mental construct around the code. e.g. deleteRecords(); is not better than if let x = deadRecords() deleteRecords(x); Sure, it looks messier but there is value is showin…
Finding the right abstraction isn't always easy. Sometimes if I just put it down and let it slosh around in my brain for a few days, it comes to me. Like your idea of pruneDeadProjects()!
The programming strategy of "less typing, more thinking", it's a good one for avoiding RSI.
Re: My personal C coding style as of late 2023
#274> #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 meaningf…
This is length of a null-terminated string, e.g. lengthof("abc").
OK, thanks I don't use C much and definitely forgot about that. But my point still stands doesn't it, in that the author is using these preprocessor macros for general arrays, which don't have a special terminator sentinel.
Re: My personal C coding style as of late 2023
#275Earlier quoted context omitted.
> 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 questi…
> 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. How many of them started before stdint.h existed? AFAIK, it's a somewhat recent addition to the C language, and IIRC, for a long time even after it became part of the C standard, some popular C compilers still didn't have…
[deleted]
Re: My personal C coding style as of late 2023
#276Honest question: why C? I've been writing C++ firmware for SoCs, supposedly an area where C is supposed to be king, and C++ was just as good, except it came with all the batteries included. So, why C?
In my case :
- I prefer functions over classes.
- no mangling of exported names, the binary is re-usable as API.
- in the long term, the C source code is more re-usable in other projects than C++ ones.
and more like this.
Re: My personal C coding style as of late 2023
#277I would not use typedefs as this should not be in the C syntax (like enum,switch, and much more).
The primitive type names should be native, but to "fix" C I prefer using the C preprocessor (I use it for namespace/name mangling too). This is not perfect, but should be already way more than enough.
With proper preprocessor usage (without going amok), one can write one compilation unit software roughly easily.
Re: My personal C coding style as of late 2023
#278Been there. Writing u8 instead of uint8_t may seem like a time saver, but in reality it makes it more difficult to read and reason about.
If you pack too much information, you are taxing your brain more, you are slower to analyse the code and you make it easier to make mistakes.
Now I much prefer code that is as verbose as possible.
Re: My personal C coding style as of late 2023
#279Honest question: why C? I've been writing C++ firmware for SoCs, supposedly an area where C is supposed to be king, and C++ was just as good, except it came with all the batteries included. So, why C?
In my case : - I prefer functions over classes. - no mangling of exported names, the binary is re-usable as API. - in the long term, the C source code is more re-usable in other projects than C++ ones. and more like this.
sure... and what about time spent debugging yet another unallocated/untimely freed/off by 1 pointer mistake?
ps. you know you can write C++ code that is functional and use free functions primarily instead of putting everything in classes?
Re: My personal C coding style as of late 2023
#280Honest question: why C? I've been writing C++ firmware for SoCs, supposedly an area where C is supposed to be king, and C++ was just as good, except it came with all the batteries included. So, why C?
> it came with all the batteries included
Sometimes you do not want, or need, all the batteries.