Am 15.12.18 um 02:49 schrieb David Hendricks:
This topic came up in a patch submission, and it
occurred to me that we
never actually wrote down canonical limits in the wiki. So I went ahead and
added the proposed limits here:
thanks, this was bugging me for long, but I didn't know when it was
It seems that we never really decided on 112-characters vs. 120-characters,
so I wrote down 112-characters for now.
I guess time decided. 112 chars feels more than enough, IMHO.
At least most were satisfied with
an 80-column "soft" limit and an exception to the limits for tables...
Regarding exceptions, I was taught that function signatures in header
files are an exception too. I don't mind either way, but if the rules
disagree with the current practice, we should make that explicit.
Actually, I can't recall ever hearing about a soft limit. Though, I like
the idea. I tried to formalize something like that once with the notion
of a "visible width" during a [coreboot] discussion. Quoting myself here
in case somebody is interested:
[...] I see three
major cases that people care about:
1. Function signatures,
2. Code lines and
3. Code lines containing string literals.
Let's assume 72 chars of visible width (line length minus the inden-
tation) is enough for code lines. If we say two additional indentation
levels are always reasonable (a third might be too, here and there) we
would be at 96 chars.
So I would compromise as follows:
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.
 I think we should treat the latter two separately because you can
easily argue that lines with a string literal might get too long but
if you apply the same rules to regular code, you'll get all the
crappy stuff (too many levels of indentation, unnecessary long, less
distinctive identifiers etc.).
Full message here. That would only apply to the bulk of the code and
comments. For me, carefully hand-formatted passages (like tables) are
always an exception.