Open Kerilk opened 2 years ago
Regarding the specific style we use, in my opinion there should not be a strong requirement to match the formatting used by the current headers, especially because the the current formatting isn't always consistent. As long as the style looks nice (yes, I know this is subjective) and is applied consistently it will be a readability win.
I do have a slight preference for styles that can be generated easily, although if we run clang-format as part of a generation script this is less important, also.
Regarding the specific style we use, in my opinion there should not be a strong requirement to match the formatting used by the current headers, especially because the the current formatting isn't always consistent. As long as the style looks nice (yes, I know this is subjective) and is applied consistently it will be a readability win.
I do have a slight preference for styles that can be generated easily, although if we run clang-format as part of a generation script this is less important, also.
Indeed, I started moving away from the style more and more. I would be very open to suggestions on the style to adopt. I am not opposed to radically changing the style, and adopt something used by other related communities.
Side note: based on my current experiments, there are a slight caveats with clang-format: it does not handle function pointers and function pointer typedefs extremely well.
This is a straw-man PR that formats and enable stye checking for the headers.
The reasoning behind this PR is thus:
For now this PR uses clang-format using a custom style derived from Mozilla, which was the closest to ours. I assume it can still be refined. To apply the style to the headers run
clang-format --style=file -i `git ls-files *.c *.h`
from the headers directory.