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?<div><br></div><div>That would be great facts to know... (don't currently have the time to analyze the stdlib)</div>
<div><br></div><div>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.  <br>
<br><div class="gmail_quote">On Fri, May 22, 2009 at 8:00 AM, Jess Austin <span dir="ltr"><<a href="mailto:jess.austin@gmail.com">jess.austin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Thu, May 21, 2009 at 3:45 PM, Aaron Rubin<br>
<div class="im"><<a href="mailto:aaron.rubin@4dtechnology.com">aaron.rubin@4dtechnology.com</a>> wrote:<br>
> On Thu, May 21, 2009 at 12:28 PM, Jess Austin <<a href="mailto:jess.austin@gmail.com">jess.austin@gmail.com</a>> wrote:<br>
>> On Thu, May 21, 2009 at 1:01 PM,  Aaron Rubin<br>
>> <<a href="mailto:aaron.rubin@4dtechnology.com">aaron.rubin@4dtechnology.com</a>> wrote:<br>
>> > subjective ones.  Arguing over *how* to break lines is actually a pretty<br>
>> > strong argument that time is wasted spent on such issues.  A longer line<br>
>> > width would reduce these arguments, since less would need to be wrapped.<br>
>><br>
>> This is an unsupported, and IMHO largely incorrect, assumption.<br>
>> Several correspondents have noted that they most often overrun their<br>
>> intended line length by one or two characters.  Just as there's<br>
>> nothing magical about the number "80", there's nothing magical about<br>
>> "81" or "82" either.  In a regime of 90-character lines, the limit<br>
>> will most often be exceeded by one or two characters.  The same will<br>
>> happen in a regime of 100-character lines, etc.  We'll still need to<br>
>> break lines, and wrapping them in parentheses will still be the best<br>
>> way to do that.<br>
><br>
> How can you argue that it wouldn't create *less* line wrapping?   According<br>
> to your argument having 10,000 character width lines wouldn't create less<br>
> line wrapping either.  Nobody ever said it would eliminate it, just reduce<br>
> it.<br>
<br>
</div>My point is that line length is a habit of programming.  Like any<br>
habit, it is largely determined by the context in which it arises.<br>
Different contexts will yield different habits.  I'll accept your<br>
implication that there are some idioms that will never take more than<br>
100 (is that the number you like?) characters regardless of the<br>
verbosity of the programmer, and I'll further stipulate an inverse<br>
linear relation between line length and line-breakage rate.  However,<br>
I'm pretty confident that this relation has a _very_ shallow slope, so<br>
that if we assume 10% line breakage at 80 characters, I'd expect 9%<br>
line breakage at 100 characters.  Is a 1% absolute benefit really<br>
worth any argument at all?<br>
<br>
I doubt you can disprove my slope estimate, but if you try please<br>
understand how few projects in the wild are completely accepting of<br>
excessive line length, and base your statistics only on programmers<br>
who primarily code in those environments.  If you succeed in<br>
overthrowing heaven and earth here, you'll change programming<br>
environments and habits for everyone.<br>
<br>
Jeremiah's point concerning argumentation rates is also valid.<br>
<br>
cheers,<br>
<font color="#888888">Jess<br>
</font></blockquote></div><br></div>