On 29.05.2018 14:23, Patrick Georgi wrote:
Am Fr., 25. Mai 2018 um 18:40 Uhr schrieb Nico Huber nico.h@gmx.de:
o Set a hard limit around 100 chars (96 would be a nice number). o If a line doesn't contain a string literal, recommend a visible width <= 72 chars.
As Sam noted, it's hard to find tooling for that. But even with 96 characters clang-format's output looks much better than with 80.
It's not that hard to grep.
diff -u | grep '^+' | grep -v '^+[_a-zA-Z]|"' | while read; do echo $REPLY | \ sed -e's/[[:space:]]*([^[:space:]]*)[[:space:]]*/\1/' | \ wc -c done
If anybody knows perl, that would probably be a two-line patch to checkpatch.
One thing your transfer of the 72 char rule from continuous text to code doesn't take into account is that in code, individual lines often stand on their own. Consider the following block:
It was really just based on the assumption that you don't have problems with line breaks at the first indentation level. If we'd really still have to break too many lines, we could also just use the same rule with 80 chars visible width.
/* this function will fill the corresponding manufacturer */ void smbios_fill_dimm_manufacturer_from_id(uint16_t mod_id, struct smbios_type17 *t)
I wasn't sure about function signatures... maybe no 72-char recommen- dation for them? Just let them run to the hard limit? (I've filtered lines starting with [_a-zA-Z] above, maybe that's enough?)
We should probably define a rule for breaking signatures anyway. e.g. either align all parameters with the opening parent, or always break after it and align all parameters at one tab. The mix above makes my head ache.
{ switch (mod_id) { case 0x2c80: t->manufacturer = smbios_add_string(t->eos, "Crucial");
This fits on one line, even with our current rules. With a visible width of 55 chars, there would still be 17 chars space left. But that doesn't apply here anyway, because of the string-literal exception.
break;You'd never set a chapter in a book like this except maybe as an art project (that I'd decline to read). It's more readable after collapsing both the header and the add_string call to a single line each (two "carriage returns" in the middle of a statement less), despite passing the 72/80 character limit - except if you're on an old-fashioned terminal where part of the line is missing because it's too long now.
If people write chapters full of documentation in comments, by all means, let's limit that to a 72 character width (plus indentation for "/* "). Code formatters generally leave comments alone if they can help it, so that requires a different tool if we want to enforce it.
A simple script would suffice, imho. As long as the rules are kept simple.
Nico
-
Nico Huber