Re: [Python-ideas] 80 character line width vs. something wider
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 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.
This sentiment reminds me of those road-construction enthusiasts who are always certain that the _next_ newly-built highway will end traffic jams forever. What happens instead is that the new road fills with cars too, and it still takes forever to get to work.
cheers, Jess
ps. ride a bike!
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 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? 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.
This sentiment reminds me of those road-construction enthusiasts who are always certain that the _next_ newly-built highway will end traffic jams forever. What happens instead is that the new road fills with cars too, and it still takes forever to get to work.
cheers, Jess
ps. ride a bike!
On Thu, May 21, 2009 at 9:45 PM, Aaron Rubin aaron.rubin@4dtechnology.comwrote:
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.
He's not arguing that it wouldn't create less line wrapping, he's arguing that it wouldn't create less arguments about line-wrapping, and thus wouldn't reduce the wasted time spent arguing about line-wrapping.
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 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? 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
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 jess.austin@gmail.com 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 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?
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
participants (3)
-
Aaron Rubin -
Jeremiah Dodds -
Jess Austin