Closed okke-formsma closed 4 years ago
It looks like that also includes a formatter, which we get for free since its in ${ZMK_ROOT}/zephyr/scripts/
on mac/Linux. A bit more of a pain on Windows, but if we have a CI step to report errors they can always commit -> check -> format based on the results. (You can also technically set up GitHub Actions to run stuff on PRs and commit changes for you if you trust the in-place fix arg, but for a random script like this I'm not sure I'd trust it).
Assuming a style (any style) is picked, there is then a second discussion of if you should make all code compliant in a big fix-up commit, or fix files as you go etc. I personally lean on the "do a giant commit and get it over with" path, especially now that more recent Git versions let you ignore certain commits so you can filter it out so git blame
etc all work sensibly and aren't destroyed.
I personally lean on the "do a giant commit and get it over with" path,
I agree. Makes it easier to write code following the conversions too because it's around already. Even if we just did the in-place fix, tuning the changes could be done later/incrementally if we wanted.
uncrustify --replace --no-backup -l C -c ../zephyr/.uncrustify.cfg src/behaviors/behavior_tap_hold.c
worked like a charm for me. I don't care if we do a big change right now or not, but let's at least make all new additions crust-free!
https://docs.zephyrproject.org/latest/contribute/index.html#uncrustify
I would actually make an alternate suggestion, and suggest clang-format
based approach instead. There's tons more integrations and support for that instead of uncrustify
. It should be easy for us to automate checks for PRs using it as well.
Thoughts?
I'd like to propose to use the zephyr coding style, which is the kernel coding style