Reasons for source code line length limits (was: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?)

Gene Heskett gheskett at wdtv.com
Mon Dec 8 06:07:49 EST 2014


On Sunday 07 December 2014 23:44:40 Ben Finney did opine
And Gene did reply:
> jtan <admin at grails.asia> writes:
> > One reason why you would want max length 79 is because of working
> > with terminals.
> 
> That reason is decreasingly relevant as terminals become virtual, in a
> display window that can be much larger if we choose.
> 
> Much more relevant is the ability to have two or even three code
> windows side-by-side, for comparison during a merge operation. For
> this purpose, a 75–80 column limit is a great help.
> 
> But regardless of display technology, the biggest reason to stick to a
> limit like 80 or less is: reader technology. The ability for humans to
> comprehend long lines of text is poor, and there *is* a cognitive point
> beyond which it's not helpful to have longer lines.
> 
> That line-length limit is different for different people, and many
> readers (and especially code writers) will fool themselves that they
> can read longer lines while unknowingly harming their comprehension.
> But for sure, it remains relatively constant across generations of
> humans, no matter how the display capacity increases.

This last point about line length vs comprehension, I am glad you 
mentioned, Ben. I still work in assembler on smaller, narrower bus 
machines, and I find that the one operation on data per line of source is 
a great help in tracking what the code is doing,  The biggest problem with 
that is that most assemblers format the output listing so the comments 
column starts at column 40 or so.  This 80 column limit, purely arbitrary, 
often results in the printout listing being clipped off, or is line 
wrapped by the printer driver, severely reducing the value of the comment 
when you want to revisit that code later for some reason.  For that 
reason, I generally do my assembler listing printouts with the -olandscape 
switch in effect.

Even in the gcode I write (I have some cnc mill and lathe machines) is 
usually wide enough that the landscape mode for the paper copy is used.

Now if one could buy 3 ring binders for landscape printouts. But ask for 
those at Staples and you, like the sign says, get the dumb looks for free. 
:(

Some languages need character wasting wrappers around the variable names 
used, and in gcode that is a 3 or 4 character "wrapper" dependent on 
whether its to be local to the subroutine, or is globally visible from 
anyplace in the program. Gcode itself hasn't a line length limit that 
matters, 32k IIRC, but I still like to limit data manipulations to 5 
additions and maybe a couple of mul's per line. However for me, that has 
comprehension problems for the exact reason that it winds up doing far 
more data manipulation per line, so I will often use a local variable, 
with one manipulation per line, a heck of a lot easier to understand even 
2 weeks later as my short term memory isn't as good as the years go by, 
and there are now 80 of them.

So it is a valid concern Ben, thanks for mentioning it.  I have an intense 
dislike for folks who think they should build an empire state building in 
one line of code.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS



More information about the Python-list mailing list