[flashrom] 80/100/132 column line width policy

[Nico Huber]

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:
> 
>  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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xBD56B4A4138B3CE3.asc
Type: application/pgp-keys
Size: 7940 bytes
Desc: not available
URL: <http://mail.coreboot.org/pipermail/flashrom/attachments/20181219/d3b418a9/attachment.skr>