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