Hi,
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: https://www.flashrom.org/Development_Guidelines#Coding_style
thanks, this was bugging me for long, but I didn't know when it was discussed.
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:
- Function signatures,
- Code lines and
- Code lines containing string literals[1].
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.
Nico
[1] 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[2]. That would only apply to the bulk of the code and comments. For me, carefully hand-formatted passages (like tables) are always an exception.
Nico
[2] https://mail.coreboot.org/pipermail/coreboot/2018-May/086834.html
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.
This makes sense, but can linters be taught the difference between source and header files? It would be nice to enforce the hard limit via commit hook.
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:
- Function signatures,
- Code lines and
- Code lines containing string literals[1].
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.
Nico
[1] 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[2]. That would only apply to the bulk of the code and comments. For me, carefully hand-formatted passages (like tables) are always an exception.
Nico
[2] https://mail.coreboot.org/pipermail/coreboot/2018-May/086834.html
-
David Hendricks -
Nico Huber