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

1–10 of 466 posts

Re: My personal C coding style as of late 2023

#2

Post by david2ndaccount »

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.

Re: My personal C coding style as of late 2023

#7

Post by MBCook »

A lot of this makes sense to me.

I’ve started writing a bare metal OS for Arm64. It’s very early but I’ve done some similar things. I’m using pascal strings, I’ve also renamed the types (though I’m using “int8” style, not “i8”).

I quickly decided that I never intend to port real software to it, so I really don’t have to conform to standard C library functions or conventions. That’s given me more freedom to play around. C is old enough to have a lot of baggage from when every byte was precious, even in function names.

It’s nice to get away from that. Much like the contents of this post, that plus other small renamed just ended up feeling like a nice cleanup.

Re: My personal C coding style as of late 2023

#8

Post by superchroma »

petabytes wrote: post #4
Gibbon1 wrote: post #3

[flagged]

What's wrong with it?

Well, from a team perspective, it's extremely opinionated and hostile to newcomers and messes with core language features at the expense of readability. If it's your personal codebase then do whatever, obviously.

Re: My personal C coding style as of late 2023

#9

Post by ForkMeOnTinder »

> To beginners it might seem like “wasting memory” by using a 32-bit boolean

Maybe I'm a beginner then. He lists a few cases where it's not worse than sticking to 8-bit bools, but no cases where it's actually an improvement. It still wastes memory sometimes, e.g. if you have adjacent booleans in a struct, or boolean variables in a function that spill out of registers onto the stack. Sure it's only a few bytes here and there, but why pessimize? What do you gain from using a larger size?

Post reply on HN