News: 1590992885

The reason for the 80 column limit is not the terminal screen size but the 80 column punch card. If you are old enough the phrase "Do not bend, fold, spindle or mutilate" means something to you.

It was actually a 72 column limit, because the last 8 positions were for sequence numbers. After you dropped a card deck once, you found out that if you had punched the sequence numbers, like you were supposed to, you could run the mixed up cards through the mechanical sorter (or look at the numbers and sort by hand).

Yep. I remember them well. You would if your card deck was over 2100 cards in size and that was just for the program itself. The data that it would use when compiled was another 400 cards. At least we could get the output on paper tape.

Wasn't 'George 3' wonderful...

Things changed for the better when the Poly got a Dec PDP 11/40 with a single RK05 disk drive.

You quickly learned to get a marker pen, and put a coloured diagnonal line across the deck , from bottom left to top right. If any cards were out of order, it was immediately visible.

If you are old enough the phrase "Do not bend, fold, spindle or mutilate" means something to you.

You mean that one album by a Skinny Puppy cover band?

A diagonal line or two drawn across the top of the deck was usually enough to get things back in order.

But as for line lengths in code, I get around 300 characters on my UWHD monitor in Visual Studio, but I'll still break lines that have complex if/while conditions with lots of && and || because I think that makes them easier to understand.

One reason is to stop people having too many levels of indent. Especially helps with an 8 width tab stop as indent.

Back in those days the programming limits weren't on the amount of ram available but more the length of available elastic bands!

Programming FORTRAN IV on an ICL at uni was literally a juggling act.

Still coding to 71 characters, 72nd character the continuation line, and the last 8 the sequence number in IBM assembler, but when I started in 1990, we used 132 column emulators for listings, system dumps etc. Ah, VM (now z/VM), what a wonderful development and test environment!

> It was actually a 72 column limit

And anything after the 72nd column is a comment.

I had to explain this to people trying to learn Fortran

"It's like it's ignoring the end of the line"

Errr, yes it's supposed to

And one quickly learned to sequence by tens or hundreds in order to allow for inserting patches.

Punched cards with sequence numbers worked pretty well compared to stuff like paper tape, early disk drives, and even magnetic tape--all of which tended to be probabilistic media. IMO, About the only things that worked better back in the good old days was that keyboards. If we're so damn smart, why don't we have $12 keyboards with the touch and feel of IBM Selectric typewriters?

from my prehistoric experience, dropping - or overturning - one of those grey trays containing up to 2000 punched cards used to be known as a 'floor sort'...

I'm definitely on-board with Linus on this one. I know we developers can be a sentimental bunch, but the 80 column de-facto limit has seemed pretty anachronistic now for a very, very long time.

I'm definitely on-board with Linus on this one.

Me too - and its not that often it happens. I generally dislike the mans methods and ways of working.

However, looking at the way development is conducted in a modern UI, with code snippets, intellisense (your feature naming may differ), and restrictions simply make method naming less meaningful.

Upgrade or live with the wrapping seems fair enough - its backward compatible, optional, and provides value in the upgrade path. That is generally how forward leaps are supposed to work.

I would just say here that if line lengths get too long, then it gets difficult for your eyes to find the beginning of the next line. That's why dead tree newspapers arrange their text in fairly narrow columns.

No, that's an old typesetting thing - a perpendicular problem to cards - the typesetter can gather the letters and hold them as a line between thumb and forefinger for placing in the press.Also good for moving blocks of test around the layout.

Agreed, but then upping the limit to 100 is just bonkers. Why should there be a limit anyway ? Just line-wrap when you get to the edge of the screen. If you type over five lines, who cares ?

Of course, that does imply that the command line utility needs a rather drastic upgrade, but that would really be putting his code where his mouth is.

There needs to be a limit or it just becomes a willy wanging exercise. On my 8K monitor with a 6pt font I can easily get 512 character lines, if you can't read them that's your problem, you must be too old, have too poor eye sight (because you're too old) and have stone age hardware (coz you're a grey beard) etc.

80 characters is roughly what a brain can read and comprehend both the start and end of the line. If you're blessed with really big monitors, 80 characters means you can have several files open side by side without wrapping - as a developer, nothing I write is in isolation, the more context I can have visible on screen at one time is beneficial.

One thing I've noticed on projects with no line length limits is more complex code - longer lines allow more levels of indentation before a developer is prompted "hey, this is a bit too long now, maybe refactor?".

A lot of my development is in Python, and there is a good trend to use psf/black to format your code automatically. It removes almost every single tedious discussion about code style, and everything looks the same. It has chosen a default max line length of 88; its not clear whether this was accidental or deliberate, but 88 is a white supremacist "hidden number", so I either change it to 80 or 90, depending on whether people argue for longer lines or not :)

I notice Linus is not also suggesting a change in git commit message format from 50 chars for title, 72 for comments, both of which are derived from 80 character terminals.

All my retro-art ASCII cats print out puurrrfect at 80 lines and these old people still care about... old dusty code? I followed that link to a "webpage"... no Javascript, no auto-play videos, no voting buttons, no emojis.... only 5 followers.... WOW these people are soooooooo ANCIENT they don't even understand... visit my patreon and help fight the old people... join us on Discord and M.AKE A.SCII G.REAT A.GAIN!!!

Did AManFromMars somehow manage to mate with Bombastic Bob?

Shudder

As usual Linus makes a lot of sense. However the lack of colour in the reply makes it a little disappointing :-)

On the other hand, the opposite should also true to a certain degree, considering how code optimisation tends to be forgone in favour of just upping the system requirements.

Terminals could wrap at 80 chars but centre justify, just like modern web pages.

... but I quite like alternate line background shading when lines get >100 chars or so - like we use in wide tables. Thank goodness for stripes.el. What, we don't all use emacs as our terminal? Ok, just me and a few emacsists ...

Thanks for the tip - I was struggling to comprehend a pins constraints until now!

And mostly I still do. However I once worked with a blind programmer, and had an eye-opening conversation regarding line length limits and how TABS-for-indent are really desirable.

I'm not trying to open the argument, just saying it's always interesting to listen to other perspectives.

(In addtion, he also used text-to-speech, and as a result was really good at catching typos and spellling errors).

This needs to be forwarded to Torvalds, as I doubt he has heard the topic from this [important] perspective.

If a line of code is much longer than 80 chars then it becomes difficult to follow - the main reason for a limit on line length is the human brain.

If you need to debug or modify a program written by another author then excessively complex lines impede understanding. A well written program is easy to follow - not written like a contender for the obscured C contest. Unfortunately all too many current programmers never think of the poor sods who may need to maintain their programs in the future.

(The assembler code for the RSX-11M operating system written by Dave Cutler was far easier to follow than much of today's code in higher level languages.)

As some have already hinted, there are cognitive limits on line length. 80 characters are, purely by coincidence, close to the sweet spot. (I'll 'fess up to "citation needed," can't be arsed.)

Now the anachonism that really makes me laugh is the preference for having the terminal emulators look like a 1980 green on black screen. Dark on light is more readable. (And don't get me started on the current fashion for Dark Mode.) At least we all get our own choice on the colours though.

Oh dear, all my terminal windows are green on black 80x24! I must be a dinosaur!

I usually make sure my comments etc are within 80 chars with line breaks etc. But if some code line-wraps then it is what it is.

I used to have the terminal windows start up with black text on a white background. Then, recently, someone on this forum was reminiscing about DEC terminals. So I've now set it to be green on black.

The user prompt, however, is a blue "$" and the superuser prompt is a red "#", so what would that make it? A VT240?

As usual, people are obsessing about the technology: yes, punched cards were 80 columns, with only 70 useable, yes that does not matter any more. But that's not why relatively small line lengths are a good thing. The reason for this is something that typographers and book designers – people whose job is to create readable text, unlike Linus – have known for a long time. Have you ever wondered why books whose form is driven by the text they contain (so not photobooks etc) are the shape they are? In particular why are books taller than they are wide? A book which was wider than it was tall would physically better to read, because the paper would lie flatter, so why are they the shape they are?

It's the same reason that books 'waste' so much paper: a well-typeset book will have margins which occupy about half the page area – half the paper, an expensive resource, is being 'wasted'. Why? The answer is the human visual system which, unlike the technology, has not changed very much in the last century. And people whose job it is to understand this stuff have done research, and the answer is that line lengths somewhere between about 50 and about 80 characters make text most readable. If lines are too long (or the leading between the lines is too small) then the 'flyback' at the end of the line is both slower, and more likely to pick the wrong line start, and readability falls to bits. If lines are too short you spend too much time in the flyback.

And now someone is going to say 'but we're not talking about text': yes, we are. Programs are text: people read programs: if they don't then they can't find problems with them, understand them, or improve them. Everyone has joked about 'write-only code': well, that's what code with very long lines is.

And of course, there is an argument that it's OK occasionally to have very long lines: everyone has had the experience of some fragment of code where you have to add lots of odd breaks to make it fit in the width, because there are lots of long names or something. So, OK, those lines are fine, other things being equal. Except they're not, for other reasons. Let's say I'm reading/writing code with the occasional line which is 200 characters long. And I'm not using a pretty-printing editor which will dynamically reformat code for me. So if I don't want those lines to wrap in some horrible way (or be lost to the right of the window), I now have to make my window 200 characters wide. And now I can fit half as many windows on the screen as if they were 100 characters wide, and almost all of the extra space in these windows is wasted, and I've burnt half the screen space on my screen(s), which is an extremely precious resource (and again: it's not a precious resource because it's expensive, it's a precious resource because of the human visual system.)

And of course, there is, in fact, a technical fix for all this, if we could only move on from the 1950s and design technology around people. We could have editors which treat code as a structure which can be dynamically reformatted depending on the window width the person editing or reading the code wants. Well, I used one of those in the late 1980s and it was fine (if buggy). But that was the late 1980s: that's thirty years in the future, because it is 1956. Last year was 1956, next year will be 1956: it will always be 1956.

> Let's say I'm reading/writing code with the occasional line which is 200 characters long. And I'm not using a pretty-printing editor which will dynamically reformat code for me.

Isn't that the exact crux of Linus's argument? That you should get a better editor, which can handle this?

Isn't that the exact crux of Linus's argument?

Seems to be, BUT I've yet to see an editor that can auto-wrap a 100-200 char line of CODE and still leave it readable in the context of the rest of the screenful.

Like Linus, I'm a microemacs fan. Microemacs 4.00 does an excellent job of wrapping plain text and has a reasonable go at wrapping code: at least the wrapped part of the line keeps the same indent level, but I still find that I often need to manually edit the wrapped line to keep the code neat, so this is not (yet) a solved problem.

I normally program with two 80x24 console windows for convenience (one for source editing , the other for compiling & testing, manpage lookups etc. Currently I'm using a Lenovo T440 with a 1600x900 screen, so the pair of consoles can have an easily readable character size and still sit side by side with no overlap. So, by itself this physical setup is a good argument for using 80x24 edit windows, at least in my usual programming environment.

Some of these concerns boils down to good code hygiene.

When I started learning C#, one of the things that felt visually wrong was the "massive" code indentation. Four spaces!

It felt wrong, because once you had nested a couple of levels, you'd need a wider monitor.

But eventually I realized that I do not actually want nesting that deep. It is better to move stuff into separate functions or rework the code (i.e. delete chunks that just aren't necessary). E.g. LINQ can be very effective at eliminating for-loops, thus saving one level of nesting.

I also think that line lengths should generally be kept within civil lengths, but I do not mind a 200+ character long line in the middle of a 200 line code file. However if all the lines are long, then I'll probably quit on the spot. My oldest boy is almost six years old and it is soon time for him to earn his keep anyway.

...but the article has "Samsung-derived" and "better performance" in the same sentence. Was that deliberate?

Linus seems to be worried that people splitting statements over multiple lines unnecessarily makes line-oriented tools harder to use effectively -- he cites grep, but there can also be problems with other tools, such as diff when a line is split after an edit because the statement got longer.

However, as others have noted, text over about 80 columns is harder for humans to read.

The answer, surely, is to improve the tooling -- produce searching and differencing tools that understand the syntax of the the language being used and work on a statement by statement basis, rather than treating sourcecode as plain text. We can't change humans, so we're stuck with the readability limit ... but we can change the tooling.

I'm not in favour of hard-and-fast rules, but I am in favour of easily-readable code ... and that leads me to favour multi-line statements over long lines, while not eschewing longer lines completely -- sometimes there's a need for them.

Thats an invalid argument for grep - its had the -Cn option for showing hits in context for decades now.

This fixes the split-line issue just as well as piping grep output into less fixes the long line issue.

Gives me an excuse to drag out my old story about a DECWriter - basically a hardcopy terminal - back in the early 80s.

One day it started refusing to print anything beyond column 80, no matter the length of the line. If the line was longer, then it would print 80 characters, then carriage-return line-feed, then continue the line.

80 characters - very significant! We spent days checking and re-installing every piece of software we could think of that might be causing the problem. But it still wouldn't print beyond column 80.

Then I decided to actually look at the DECWriter itself. And discovered a pencil that had fallen into it and become jammed.

It was pure coincidence that it was after column 80 that the print head encountered the jammed pencil and took evasive action.

Massive screens compared to those 40+ years ago gives a lot more options for people to work in a manner that works for them. I remember working on 40 column displays then getting a better display that could do 80 columns - it was enlightening..

Given that nobody prints out on hardcopy any more and 80 column printers had their limitations in the day - hence 132 column devices and as Unix and Linux have always had termcap (terminal capabilities) to cope with terminal differences "stty columns 132" or "stty columns 1000" all work as intended

All editors since the year dot have had line wrap capabilities that allow you to fold longer lines within the editor to make them readable without scrolling if you want to work like that and no changes to line lengths are made to the saved file either..

On the back of that, virtually all programming languages have a way to cope with longer lines either with a line wrap (\ in c) so a lot of this will come down to personal preference based on what the person is doing / what hardware they have available to work on.

I'm just a bit bemused as to why this has suddenly become an issue in 2020 when its had long established solutions for many decades.

Are we re-learning things we already know the answers to as people refuse to look at history and standards as they always assume they can do it better with zero knowledge and background. This seems to be the norm these days.

..the number of Luddites in the tech world...

Tech evolves. Try it :)