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

Stefan Tauner stefan.tauner at student.tuwien.ac.at
Sun Mar 11 23:00:42 CET 2012


On Sun, 11 Mar 2012 16:51:08 +0100
Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:

> Hi,
> 
> we're hitting the 80 column limit in our code in ways which actually
> reduce readability for the code. Examples are various multiline messages
> and complicated nested code where refactoring to a separate function
> doesn't make sense.
> 
> Keeping the old 80 column limit is not really an option anymore.
> Standard terminal sizes have one of 80, 100 or 132 columns.
> Given the monitor resolutions many people have nowadays, I think it is
> safe to say that you can fit two xterms with 100 columns horizonally
> next to each other. 100 columns should also be sufficient for a msg_p*
> of roughly 80 columns of text.
> 132 columns provide more leeway, but IMHO that would be too wide for
> good readability (and my screen can't fit two xterms side-by-side anymore).
> 
> Of course some files have sections where any column limit is not
> acceptable (board lists etc.), but the column limit violations should be
> limited to the affected file sections, not whole files.
> 
> Comments?
> I'd like to get this decided today or tomorrow so we know where we need
> line breaks in Stefan Tauner's new struct flashchip patch.

i would prefer more complex rules than a simple "break the line at a
maximum of n chars or die".
increasing the hard limit would lower the frequency for anger-inducing
line breaks on my side a bit, but won't solve the problem completely.
i think i once proposed something like the following after you went
offline, so i am repeating it now in an RFC.

x chars soft limit (e.g. 90);
y chars hard limit (e.g. 120);
o chars overhang (< 5 or "common sense").

before reaching x one should try to break at a convenient spot like
logical operators for multi-term conditions, parameter names etc just
like one usually does before hard limits.
most printed text strings should have their line breaks before x at
usual indention depths ((1 to 3)*8).

expressions that fit in y chars completely, but not in x should *not* be
split.

same exceptions for long tables as used so far.

optional: expressions that fit in y + o chars, should not be split,
just for the sake of obeying the limit i.e. if it would make the
expression less readable (e.g. the case where ";" breaks the limit and
i start swearing :P)

optional #2: neither limit should apply to printed text strings. they
should be broken at "\n" no matter how far that is. the rationale is
that it is possible to see if they are sanely formatted without runtime
tests.

all of that could be replaced with a simple "we want to limit lines to
ca. y chars, please think a bit and use common sense when breaking
lines" rule imho. hard limits can never have enough rules/exceptions to
match "common sense". of course i am ignoring personal preferences
here, but i think i can cope better with "annoying" preferences of
others when reviewing patches or getting feedback than with hard limits
that make me write lines like "\tab\tab\tab  i) {". :)

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner




More information about the flashrom mailing list