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...?

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.

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.