clang format woes

437 views
Skip to first unread message

Greg Troxel

unread,
May 11, 2022, 4:34:46 PM5/11/22
to rtl433

In trying to write even a few lines of code, I ran into several problems:

1) clang-format gets a fatal error with the checked-in config.

I am using

Debian clang-format version 11.0.1-2

from Debian 11, which I feel is pretty mainstream these days, and I get

YAML:8:25: error: invalid boolean
AlignConsecutiveMacros: AcrossEmptyLines
^~~~~~~~~~~~~~~~
I see that CONTRIBUTING.md does not specify a minimum clang-format
version, but my point is really that non-ancient versions should be ok.
That to me today means Debian stable, Ubuntu 20.04 (until 23.04 maybe),
but doesn't include old LTS.

FWIW pkgsrc, which is how I usually work, has clang-format 13.

2) After running clang-reformat, on tpms_ford.c, it split a line that
wasn't split and I manually fixed it the first two times and then I
forgot the third time. It seems that a) clang-format should do the same
thing on all systems and b) the tree should be such that running
clang-format changes nothing.

3) I edit with emacs, and given that there is a clamg-format file, it
seems there should be an emacs style, so that I can get easily it at
least mostly right as I edit.


The combination of 1 and 2 adds a fair bit of workaround time, as I
can't have an uncommitted comment-out of the offending config and then
rebase.


signature.asc

Christian Z.

unread,
May 11, 2022, 6:37:42 PM5/11/22
to rtl_433
The clang-format option "AlignConsecutiveMacros" should be supported with clang-9, but the "AcrossEmptyLine" choice needs clang-12 or clang-13, not sure.

I use clang-format more as a general suggestion than a fixed rule. It would be nice to have a fine-tuned .clang-format to fit our source. It's seems I can't get the line breaking I want, like you also noticed.
On top of those annoyances there are some places where the formatting conveys meaning that would be lost with a blanket reformat of all files.

If someone has the time to really fine-tune the rules that would be appreciated. Most of the current formatting is just what turned out to be common in most files. We can change things. But not too drastic please ;)

Greg Troxel

unread,
May 11, 2022, 8:00:55 PM5/11/22
to Christian Z., rtl_433
I'm ok with most of that in theory, but it doesn't seem
feasible/reasonable to write code that complies with the current style
by hand (and there's no emacs support). And, there is a CI check for
formatting that failed on me. So I feel like I have to run
clang-format.

I would vote for:

Change AlignConsecutiveMacros value to something that works with 11.

Force-format things, even if it the result is slightly annoying, and
add in format-off/on for cass where that isn't ok. Or add a comment
instead and don't worry.

Be ok with people running clang-format on files before committing,
meaning allow the random whitespace changes that will happen if the
file wasn't formatted right.

For now, I expect to make only small changes to tpms_ford if I figure
out something new, and to look at python, so this isn't urgent and of
course isn't that important.

FWIW, the emacs list of c-styles is

awk bsd ellemtel gnu java k&r linux python stroustrup whitesmith

perhaps this is mostly gnu/4/no-tabs.
signature.asc
Reply all
Reply to author
Forward
0 new messages