-
Notifications
You must be signed in to change notification settings - Fork 203
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question: Is there an existing .clang-format configuration appropriate for this project? Should we create one? #451
Comments
I think for files that come from upstream musl its best to stick to the upstream style of the musl codebase. I doubt this style is covered by a pre-existing config so you might have to role your own, using a pre-existing as a starting point. For completely new downstream files I guess we could go a different direction, but maybe its better to just have once style everywhere? |
Yeah, I guess we should avoid creating yet another style for new code and instead try to match one of the existing ones, e.g. the musl one. |
The GNU style might be a good starting point: https://clang.llvm.org/docs/ClangFormatStyleOptions.html#basedonstyle ? |
https://wiki.musl-libc.org/coding-style says:
... so maybe we should start with https://github.com/torvalds/linux/blob/master/.clang-format |
Yeah, I'd be interested in seeing what happens if we apply that... |
I don't think we want to be applying that to existing code, since we are mostly a fork of musl and we dont want to introduce extra deltas for this kind of thing. For new code it seems reasonable enough as long as its true that the kernel style and musl style do indeed mostly align. |
While working on adding
wasi-sockets
support, I've been usingclang-format
to format new code (specifically,clang-format -style=webkit
as an arbitrary choice). I can see that there are a variety of styles in the existing code, presumably because they've come from various upstream projects.It would be great to have a .clang-format configuration that automatically applies the appropriate style (whatever that style might be). An easy option would be to pick one of the built-in clang-format styles and go with it, or else tweak it a bit if desired.
To be clear: I'm not proposing we do a mass reformat of all the existing code -- this would just be for new code. I'm also not proposing we enforce this automatically; only that people could optionally use
clang-format
to handle formatting, saving time for both the author (when writing code and addressing feedback) and reviewers (so they can focus on what the code does rather than how it's formatted).The text was updated successfully, but these errors were encountered: