Good stuff, Jess.  It should be easily observed...what percentage of wrapped lines in the stdlib would end at <=100 characters vs. <=120 vs. <=140, etc?

That would be great facts to know... (don't currently have the time to analyze the stdlib)

In a quick analysis of my code base (easier to analyze since it is not wrapped already at 80 or so), I find that roughly 70% of the long lines end at <=100 and 90% end at <=120.  That's a much steeper slope than you predicted.  The question I'm faced with is whether the extra 20% of 120 vs. 100 is worth it.

On Fri, May 22, 2009 at 8:00 AM, Jess Austin wrote:
On Thu, May 21, 2009 at 3:45 PM, Aaron Rubin
<aaron.rubin@4dtechnology.com> wrote:
> On Thu, May 21, 2009 at 12:28 PM, Jess Austin <jess.austin@gmail.com> wrote:
>> On Thu, May 21, 2009 at 1:01 PM,  Aaron Rubin
>> <aaron.rubin@4dtechnology.com> wrote:
>> > subjective ones.  Arguing over *how* to break lines is actually a pretty
>> > strong argument that time is wasted spent on such issues.  A longer line
>> > width would reduce these arguments, since less would need to be wrapped.
>>
>> This is an unsupported, and IMHO largely incorrect, assumption.
>> Several correspondents have noted that they most often overrun their
>> intended line length by one or two characters.  Just as there's
>> "81" or "82" either.  In a regime of 90-character lines, the limit
>> will most often be exceeded by one or two characters.  The same will
>> happen in a regime of 100-character lines, etc.  We'll still need to
>> break lines, and wrapping them in parentheses will still be the best
>> way to do that.
>
> How can you argue that it wouldn't create *less* line wrapping?   According
> to your argument having 10,000 character width lines wouldn't create less
> line wrapping either.  Nobody ever said it would eliminate it, just reduce
> it.

My point is that line length is a habit of programming.  Like any
habit, it is largely determined by the context in which it arises.
Different contexts will yield different habits.  I'll accept your
implication that there are some idioms that will never take more than
100 (is that the number you like?) characters regardless of the
verbosity of the programmer, and I'll further stipulate an inverse
linear relation between line length and line-breakage rate.  However,
I'm pretty confident that this relation has a _very_ shallow slope, so
that if we assume 10% line breakage at 80 characters, I'd expect 9%
line breakage at 100 characters.  Is a 1% absolute benefit really
worth any argument at all?

I doubt you can disprove my slope estimate, but if you try please
understand how few projects in the wild are completely accepting of
excessive line length, and base your statistics only on programmers
who primarily code in those environments.  If you succeed in
overthrowing heaven and earth here, you'll change programming
environments and habits for everyone.

Jeremiah's point concerning argumentation rates is also valid.

cheers,
Jess