My personal C coding style as of late 2023

Re:My personal C coding style as of late 2023 by vitiral on Monday October 09, 2023 @08:25AM (#37819702)

Great article. One thing for me is that I think we named our variables wrong. We should be specifying the number of bytes, not bits. I use

U1, U2, U4, U8, I1, I2, etc

Also S for "slot" aka unsigned pointer sized integer (usize_t)

Another big point is formatting code to line-up instead of with an autoformatter. When you are doing something which is almost the same but slightly different it helps readability considerably. It is also a sign of a well-loved codebase, since I've never seen an autoformatter that can do it.

Maybe we could make formatters at least auto _detect_ that code is already aligned and to just leave that code alone. Some kind of "love heuristic"

[ Parent | on HN ]

Re:My personal C coding style as of late 2023 by ggliv on Monday October 09, 2023 @09:37AM (#37820341)

Could you elaborate on the reasoning behind using byte length instead of bit length?

Most of the time when I use fixed-width int types I’m trying to create guarantees for bitwise operators. From my perspective I feel like it therefore makes the most sense to name types on a per-bit level.

[ Parent | on HN ]

Re:My personal C coding style as of late 2023 by vitiral on Monday October 09, 2023 @07:10PM (#37826618)

We almost always talk in bytes. When trying to reason about alignment it's bytes, when reading a serial IO from a file it's bytes. I hardly ever think in bits and when I do, I think in hex not decimal.

I also like that it makes all the type names the same width (notably U1/U2 vs u8/u16).

[ Parent | on HN ]