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 email@example.com wrote:
On Thu, May 21, 2009 at 3:45 PM, Aaron Rubin firstname.lastname@example.org wrote:
On Thu, May 21, 2009 at 12:28 PM, Jess Austin email@example.com
On Thu, May 21, 2009 at 1:01 PM, Aaron Rubin firstname.lastname@example.org wrote:
subjective ones. Arguing over *how* to break lines is actually a
strong argument that time is wasted spent on such issues. A longer
width would reduce these arguments, since less would need to be
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 nothing magical about the number "80", there's nothing magical about "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?
to your argument having 10,000 character width lines wouldn't create less line wrapping either. Nobody ever said it would eliminate it, just
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.