7 posts
Code style?

What is a good coding style? Of course code style doesn't make a program performant, but what is one that makes the code readable and understandable at first glance? camelCase? snake_case? How to name structs, data types etc...?

Simon Anciaux
1241 posts
Code style?

I use everything lower case with underscore to separate words. Add _t to type definitions (struct, union, enum, typedefs) with exception for basic types (u8, s8, u16, s16...).

Function names start with the module they are part of if any (file_open, file_read, file_write, file_close...), and I try not to use abbreviations which is sometimes result in long names that can be painful.

I like to have spaces around operators and never write if without using curly braces or with the content of the if on the same line. I also like to have curly braces in switch:

switch ( c ) {
case 1: {
} break;
}


I don't know it's a good style, what I think is more important is for the style to be consistent in the codebase, and if I write code for someone else, I try to use the same style as them.

1 posts
Code style?

I think some style features are pretty much arbitrary in terms of readability - i.e. nobody has proved a particular style to be universally better.

Personally, if I'm glancing at code to get a sense of what it's doing, 'readability' has more to do with appropriate levels of abstraction than literal writing style. I like to keep functions around that implement a concept simply and clearly, even if I'll end up replacing them with some wild inline, optimised SSE stuff.

General text readability on pixel-based screens has received lots of attention from researchers. Interestingly, their conclusions (e.g. dark text on light > light on dark, warm yellowish paper tones, n-characters optimum line lengths) are usually rejected by coders, who have different priorities.

Some coders prefer long lines and using wide, high-resolution monitors. I like to code in the park on my little Pinebook Pro sometimes, so I keep my personal stuff to a 80-character lines. There are some strange line-breaks, but at least they aren't left to the mercy of text-wrapping :)

As for naming, consistancy is the most important thing!

Being able to tell what type you are looking at might be important. However, some data structures might be purposely opaque as a form of API design. Personally, I don't typedef much stuff, I stick with the 'struct' / 'union' / 'enum' prefix. There are lots of times I value this decision, and equally many where I regret it.

C doesn't have namespaces, and is often compiled as one big compilation unit. As such, its important to never duplicate symbol names. My advice is to imagine names as a folder structure. For example:

'mylib_maths_trig_sin()'

'MathsLibTrigSin()'

'Helpers_Sin_f()'

'myapp_calculate_sin_of_input_and_print()'

Are all reasonable depending on the context, and all far less problematic than straight-up declaring: 'sin()'

There are often unexpected considerations motivating style choices. For example: I prefer lowercase snake_case, but that's entirely because my keyboard has an '_' button, so I can type alphbetical names without holding down modifier keys. Totally specific to my setup, and I often change to work on other people's projects!

If you are doing collaborative work, make sure you stick to a project's agreed style - that's the only true 'correct' style.

65 posts
Code style?
Edited by Shastic on

"but what is one that makes the code readable and understandable at first glance? "

Something else that should be considered is how easy it is to type.

I use snake case for everything, but one day I want to try Casey's style of using CamelCase for functions and variables. Why? Because I think it would make typing easier. Reaching for the '_' between words is annoying because I have to stretch for it, while using CamelCase I wouldn't have to. I won't know for sure if CamelCase is better, until I try it.

CamelCase is also better because if you have long function names it takes up less space.

clang-tidy can be used to change styles. Its mentioned here: https://matt.sh/howto-c

@ matwhill "Being able to tell what type you are looking at might be important. However, some data structures might be purposely opaque as a form of API design. Personally, I don't typedef much stuff, I stick with the 'struct' / 'union' / 'enum' prefix. There are lots of times I value this decision, and equally many where I regret it."

I'm doing the same with my project. No regrets so far.

Edit: I changed my code base to Casey's method and its easier to type.

And no longer any need to put struct and enum in front of everything any longer using Casey's style, because you don't need them to search and replace.