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: > > > > 1. Function signatures, > > 2. Code lines and > > 3. 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 >
_______________________________________________ flashrom mailing list flashrom@flashrom.org https://mail.coreboot.org/mailman/listinfo/flashrom