Standardize our C formatting

[MrAlias]

Use clang-format to ensure a consistent standard formatting across the project.

TODO:

• Determine what standard to apply
• Add tooling/docs for developers to check locally
• Add CI workflows to validate code against the standard adopted

[MrAlias]

cc @rafaelroquetto

[pellared]

Maybe adopting the same standards as https://github.com/torvalds/linux?

Also see https://docs.kernel.org/process/coding-style.html

[MrAlias]

That is one of the many opinionated styles being discussed:

• LLVM
• GNU
• Google
• Chromium
• Microsoft
• Mozilla
• WebKit
• Some custom version of these

https://clang.llvm.org/docs/ClangFormat.html

[pellared]

My reasoning is that the ebpf implementation in the kernel and the samples (https://github.com/torvalds/linux/tree/master/samples/bpf) follow these standards.

[rafaelroquetto]

This is a highly subjective topic. My advice is to stick to anything that is not alien (the GNU style, despite being widespread in GNU projects, has a really interesting choice of brace placements that is not common to most C and C++ projects) - so my thumbs down to this particular one. Having said that, here's what I would consider:

• tabs vs space
• indentation (e.g. 2, 4, 8 chars)
• function brace placement (same line vs next line)
• control brace style (same vs next line)
• switch indentation

I'd say pick the above parameters in the fashion that suits the project best and see which of the styles @MrAlias mentioned comes close, then customise.

Now, to my personal taste (YMMV), I usually go for spaces (as it's easy not to mix tabs in between, but the opposite is not true), 4 chars indentation, function and struct brace placement on new lines, control block placement on the same line, switch case indented to the same column of the switch keyword - which pretty much translates to the Webkit style in the list above. Second preference is the Microsoft style because it tends to have decent vertical spacing, although this may end up bothering people used to Go standards of sandwiching code.

Having said that, there's no right and wrong. In Beyla, for instance, we've adopted the LLVM style with a few tweaks/customisations simply because it was the closest to the style we had prior to the introduction of clang-format. The value was really in adopting clang-format altogether, and never having to worry about the style anymore - we have a pre-commit hook that automagically formats the the C code and a GH workflow that ensures the code is compliant.

Another thing to consider is the adoption of clang-tidy - but I reckon that's a different issue, albeit related.