On Sun, 11 Mar 2012 16:51:08 +0100 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@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) {". :)