back to article 80-characters-per-line limits should be terminal, says Linux kernel chief Linus Torvalds

Linux kernel overlord Linus Torvalds has railed against 80-character-lines as a de facto programming standard – and has moved to make reminders to keep things short a thing of the past. Torvalds weighed in on a Linux kernel clean-up post that somehow strayed into the topic of line lengths. Some advocated for the retention of …

  1. Herbert Meyer

    not the terminal, the punch card

    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).

    1. Steve Davies 3 Silver badge

      Re: sequence Numbers on punched cards

      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.

      1. eamonn_gaffey

        Re: sequence Numbers on punched cards

        George3 : best development environment I ever worked on. Part of the ICL VME OS as I recall, a great piece of British software that unfortunately was rolled over by the IBM juggernaut....that and a sad lack of technological foresight, awareness and interest from various UK governments.

        1. ICL1900-G3

          Re: sequence Numbers on punched cards

          No! G3 preceded VME, the O/S for the New Range - 2900 series. Because so many people loved G3 and could not see a major reason to change, ICL brought out DME (Direct Machine Environment) which enabled G3 to run on 2900. G3 was indeed great, and I'm proud to have played a small part in its creation.

      2. G Olson

        Re: sequence Numbers on punched cards

        You jumped right over the Load Tape request, the poor entry level ops kid who fetched reel to reel tapes; and printed out the code on green and white paper for the software library. So much technology between paper tape and disk drive. Tch, tch, tch

        I will not admit to having direct knowledge or experience with these operations modes.

    2. ColinPa

      Re: not the terminal, the punch card

      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.

    3. KarMann Silver badge

      Re: not the terminal, the punch card

      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?

      1. bigtreeman

        Re: not the terminal, the punch card


        Frank Zappa - Dumb all Over

        You can't run a country

        By a book of religion

        Not by a heap

        Or a lump or a smidgeon

        Of foolish rules

        Of ancient date

        Designed to make

        You all feel great

        While you fold, spindle

        And mutilate

        Those unbelievers

        From a neighboring state

        TO ARMS! TO ARMS!

        Hooray! That's great

        Two legs ain't bad

        Unless there's a crate

        They ship the parts

        To mama in

        1. Jan 0 Silver badge

          Re: not the terminal, the punch card

          All hail Zappa, allright, but that's not the origin. It was written on the envelope that contained your credit or charge card statement, printed on a Hollerith card. You weren't supposed to damage it, because it would be reread when you sent it back with a cheque. Was Harvey Matusow the original cracker? Didn't he repunch his card to change his balance to a large positive value, withdraw the balance, then scarper from the USA with the cash?

          International banking wasn't very international back then. I knew of a guy, the departing business partner of my neighbour in the 60s, who emigrated to Australia a couple of days after maxing out his Barclaycard with professional camera equipment bought on Oxford Steet (Dixons, maybe?). He was never chased for the balance.

          1. Jan 0 Silver badge

            Re: not the terminal, the punch card

            Eek! A little googling reveals just how bad my memory may be! The person I'm trying to recall certainly wasn't "the" H Matusow, although I expect that other people have the same name.

            Better late than never.

    4. Anonymous Coward
      Anonymous Coward

      Re: not the terminal, the punch card

      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.

      1. alain williams Silver badge

        Re: not the terminal, the punch card

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

        1. Herbert Meyer

          Too many levels of indent ?

          I thought that was why the subroutine was invented.

          Smack that tab key, print it out, run a vertical rule down the listing at the tab stops, Gazinga !

          There is a subroutine to the right of the rule. Just check the variable cross reference for an argument list.

          Back to the left margin in a separate source deck.

        2. Steve Knox

          Re: not the terminal, the punch card

          8 width tab stops are more evil than 80 character line widths.

          1. Paul

            Re: not the terminal, the punch card

            Hard tabs should always be 8 character width

            If you want any other indentingb use spaces and an editor that does it right

            1. Anony Mice

              Re: not the terminal, the punch card

              No, just no. You are wrong.

              People who use spaces for indentation should be taken out the back & beaten with their keyboards.

              I'll display my whitespace how I choose, thank you very much.

              1. P. Lee

                Re: not the terminal, the punch card

                Would this be a bad time to note Python's obsession with warning about long lines?

              2. JDX Gold badge

                Re: I'll display my whitespace how I choose, thank you very much.

                >I'll display my whitespace how I choose, thank you very much.

                That's nice, but for those of us who don't work alone in their bedroom on code nobody else will ever touch, people like to bandy around terms like 'consistency' and 'standards' .

                Or maybe you locally re-format every code file each time you check it out so it's almost a per-user setting anyway and the precise whitespace details inside source-control are not important?

                1. Ogi

                  Re: I'll display my whitespace how I choose, thank you very much.

                  I don't know, for me, tabs make more sense as an indentation method. Especially if you want 'consistency' and 'standards'.

                  Using tabs means that the code always has the same indentation in the form of one tab per "indent", and it is up to the editor to display that indentation as 4 spaces, 8 spaces, or whatever the user prefers.

                  $x number of spaces should never be used for indentation, because it is fixed in the code. Someone may like 1 space per "indent" in order to fit as much in the width of their monitor. Somebody else might like 8 spaces per "indent" because they have a really wide monitor and prefer to see it that way.

                  Using tabs makes accommodating the spacing of indents client side, and therefore easy to display in the users preferred tab width. The alternative is hard coding the spaces, which means each person either has to tolerate somebody else's preferences, or has to re-indent the code before working on it (and then possibly redo the previous indentation afterwards), which is error prone and a waste of time.

                  I always use tabs for indenting, and depending on the system I am viewing it on, the "tab space" can be between 2 and 8 for the same code.

                  I admit the forced use of fixed spaces in Python is one of my long standing irritations with the language, and the only part of the PEP standards that I happily ignore in my own code. Unfortunately I can't do so when working on a big project with others, due to the hard coding of spaces, so we have to stick to "4 spaces per indent", and all be equally unhappy.

              3. CRConrad

                Re: “I'll display my whitespace how I choose”

                But not all whitespace is “your” whitespace. In code I write, it's *my* whitespace, and I'll type my whitespace how *I* choose, thank you very much.

            2. Steve Knox

              Re: not the terminal, the punch card

              Why? Why waste such a large percentage of your document on literally nothing?

        3. doublelayer Silver badge

          Re: not the terminal, the punch card

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

          I often want people to use more indent. If they are so annoyed with short lines that they start cutting try/excepts out, I will probably have to fix it later. The problem is that you end up with code that looks like this:

          class something:

          def a_function(self):

          if a_condition:

          for item in a_list:


          value = lookup_in_dictionary




          That's a very simple function, really. Yet the only complex part will be split into a 24-character worm, making it a pain to debug. And sometimes, people deal with this by working to avoid things causing an indent. If the function ends here, you can do a few excusable things. Instead of "if some_condition", you do an "if !some_condition: return" and drop down a level. If you have an else, that's out.

          There are two other methods I've seen to do this more cleanly, and both are bad. The first one is what I said earlier--they just ignore some things. Do they really need a try there? Yes they do, but they'll skip it and wait for that to be discovered later. The other is what the programming teachers told us to do. They'll take the functionality and put it in its own function, then just call that. If that function really gets used elsewhere, that's fine. If it doesn't, you end up littering your code with functions whose only point is to make the code easier to edit. A new coder doesn't understand control flow or which functions are meant as internal or external. Function names get exhausted and you end up with nondescriptive or confusing ones. Cutting eight characters to four and allowing lines to go longer allows you to keep these sources of bugs at bay.

          1. CRConrad

            Re: “which functions are meant as internal or external. Function names get exhausted..."

            And that (among other reasons) is why you need to be able to nest subroutines: Declare functions and procedures within each other.

            The only class of languages I am certain you are able to do that in are the Pascal-descendant ones.

            1. doublelayer Silver badge

              Re: “which functions are meant as internal or external. Function names get exhausted..."

              That is only of minor help. It does mean you can reuse names, and it means you don't have a risk of calling a function that isn't meant for external use. It doesn't make the code more readable or traceable. A function that declares three functions inside it and then implements all the functionality by calling them means you can take many routes through it. One that is a single function means a reader can determine easily what flow the function takes without having to skip around to the different internal functions. There is often a good reason to dislike a large function, but splitting it into multiple dependent parts so you can argue that it's separate doesn't change what it really is; it's still a large function.

            2. Man inna barrel

              Re: “which functions are meant as internal or external. Function names get exhausted..."

              As far as I know, all functional programming languages (e.g. Ocaml, Haskell) use nested function definitions.

          2. swm

            Re: not the terminal, the punch card

            "Cutting eight characters to four and allowing lines to go longer allows you to keep these sources of bugs at bay."

            I actually use 2 spaces per indent. But then again it is my code. I will follow coding standards for any group project.

    5. Tom 7

      Re: not the terminal, the punch card

      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.

    6. yoganmahew

      Re: not the terminal, the punch card

      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!

    7. Dazed and Confused

      Re: not the terminal, the punch card

      > 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

    8. vtcodger Silver badge

      Re: not the terminal, the punch card

      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?

      1. jelabarre59

        Re: not the terminal, the punch card

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

        I recall the BASIC system on our PDP-11/20 in high school had a "resequence" application, which would run through your program and re-number the lines by 10, and adjust any line number calls.

        If we're so damn smart, why don't we have $12 keyboards with the touch and feel of IBM Selectric typewriters?

        Properly done, it would cost more than $12 to build. You'd need a rumble motor to get the throbbing of the Selectric's motor, a sound card to simulate the sound of the type-ball with every keypress (and probably a slight vibration for the action as well). And custom round keycaps need to be molded. (do modern mechanical KB switches have enough travel in them?)

        1. Vometia Munro Silver badge

          Re: not the terminal, the punch card

          The beam-spring keyboards on the IBM terminals (my experience was some sort of twinax thing... 5250 rings a bell) had a clunker that did a nice emulation of the golfball. I think it was just a solenoid, but enough to make the desk vibrate with every keypress.

          1. Dehn Loder

            Re: not the terminal, the punch card

            Ah, 5251. I seem to recall it used some kind of magnetic key switch (Hall effect? Transformer-based?). The "clunker" was indeed a solenoid which impacted the heavy-gauge metal case and could be switched on or off; when off, the keyboard was quiet.. The keyboard unit itself was literally massive, must have been 3 kg at least, and over 10 cm thick. Don't get me started on the weight of the terminal itself.

            1. Vometia Munro Silver badge

              Re: not the terminal, the punch card

              I'm pretty sure this was the beam-spring variety as it was very tactile, but ISTR there were a couple (or more) different types in the vicinity, so they may have varied. The one I'm thinking of looked a bit like a VT100 with a VIC-20 for a keyboard but both on steroids and made of cast iron. The other type I thought looked more space-age with a swivelly screen on a plinth and a less stocky keyboard: that might've been the non-beam-spring one, but I honestly don't remember.

              What I certainly remember was the weight. D: I was asked to move one. Even over a short distance with someone else carrying the other end it nearly killed me. As much as I was a scrawny teenager I wasn't *that* weedy but those things were seriously very, very heavy indeed.

            2. TeeCee Gold badge

              Re: not the terminal, the punch card

              It could be TURNED OFF???!!!???

              There's somebody I once knew who, if I ever run into him again, is getting a kicking.

              Nostalgia is available here.

              1. calmeilles

                Re: not the terminal, the punch card

                "The keyboard is 530 millimeters (21 inches) by 210 millimeters (8% inches) by 100 millimeters (4 inches) and weighs 6 kilograms (13 pounds) each. The keyboard may be moved to service the machine."


                1. Vometia Munro Silver badge

                  Re: not the terminal, the punch card

                  Over 30 years later I still remember it as The Best Keyboard I've Ever Used™, it really was wonderful even if the layout seemed somewhat perplexing (though more or less the same as the original PC) and it wasn't exactly, erm, silent.

                  But they weren't joking about the weight. I'm not sure how they made them so heavy. The very thick and not-very-bendy cables (a pair of twinax, as the terminals were daisychained, and a just-as-fat keyboard cable) just added to the fun if the thing ever needed to be moved.

                  Going back to a previous comment, I think the thing with the swivelly screen was most likely a 3178. From memory it looks identical. I was surprised as it isn't twinax but it seems that the computing contraption in question (and I'm definitely not sure what it was: *probably* a System/38) could deal with both types, so the 3174 terminals were those in its more immediate vicinity and the twinax terminals were located in the further reaches. I'd hazard a guess from the appearance and vintage that the 3174's keyboard was a Model F as it isn't enormous enough to be a beam-spring.

      2. bpfh

        Re: not the terminal, the punch card

        If my BSE addled brain serves me correctly, this was why most of the old basic interpreters started at line 10 and next line was 20. Nothing stopped you inserting 1 or 2, or 11 or 12, it was just to allow you to add to the code later keeping the tens as a staticish reference to the original lines.

        All gone out the window with spaghetti coding, web development and code and content mixed wordpress themes...

        It's not yet 11 AM. Can I have my pint now please?

    9. Sean o' bhaile na gleann

      Re: not the terminal, the punch card

      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'...

    10. steelpillow Silver badge

      Re: not the terminal, the punch card

      Oh the joy when my school computer club received our weekly batch of programs back from Cambridge without having been fed into Titan - because a technician had dropped the lot in a heap on the floor.

      I was one of two sufficiently nerdy geeks (or was that geeky nerds?) to punch out the line numbers.

      But the 80-character limit also arose when home computers arrived and the TV was hijacked as a cheap monitor. 640 pixels per line was pretty much the limit of their resolution and, by coincidence, it yielded the same 80 characters. This led it to be adopted as the VGA standard.

      1. rcxb Silver badge

        Re: not the terminal, the punch card

        But the 80-character limit also arose when home computers arrived and the TV was hijacked as a cheap monitor.

        Except early computers that connected to TVs used much lower text resolutions.

        VIC20 was 22-column. ZX80 was 32-column. Getting 80 column displays required a lot of expensive upgrades to those. And when you did, 80-columns would look quite bad over RF output. SCART of course looks nice, but I'd say most went to dedicated VGA monitors.

        1. P. Lee

          Re: not the terminal, the punch card

          Indeed - 80 characters? Luxury!

          When I was a lad, we 'ad 40 characters across, 24 lines down an' none of this fancy lower case malarky on our new Apple ][+

          We dreamed of avin 80 characters. Nightmares they were, cos the Apple ][e lower case were an 'idious thing!

          An' we were glad of it!

          1. SImon Hobson Bronze badge

            Re: not the terminal, the punch card

            40 characters, you upper class wimps.

            On my first computer* I had to make do with 24 characters, and I was glad of it. It also had only 1k bytes of (static) RAM.

            Oh the joy when I upgraded to an ITT 2020 (licensed British version of the Apple ][) with disk drives, lots of memory (I also had a 64k memory card), and ... COLOUR !

            Oh that seems a distant time as I sit here with my GHz clocked processor, 8Gbytes RAM (max for the machine), and 12G of swap in use. Even my phone eclipses those early computers.

            * Ohio Superboard II, 1MHz 6502, room for 8k max of memory unless you added the expansion board. I think it was 24 characters, but that's a lot of decades ago now.

    11. Ken Hagan Gold badge

      Re: not the terminal, the punch card

      I think it was more like 65 or 66 for FORTRAN programmers (upper-cased, since this *is* your grandmother's FORTRAN) since the first few columns were reserved for something as well -- statement labels for GO TO statements if I remember rightly. (In mitigation, FORTRAN ignored all whitespace, so you could save loads of characters that way.)

    12. G.Y.

      Re: not the terminal, the punch card

      The 72-column limit came from the IBM 70X/70XX series, which read one row of holes, in binary, into 2 36-bit words. The sequence-number justification came later.

      1. Vometia Munro Silver badge

        Re: not the terminal, the punch card

        I always wondered why 36 bits was so popular back in the day... until I looked it up and the explanation was pretty straightforward: because that's how many bits you need to store 10 decimal digits, which was decreed in order for them to compete with mechanical adding machines.

        Apparently, anyway. There may be other explanations and I couldn't say which would be the most likely! Just that I have a soft spot for 36 bit machines which seem quite interesting and exotic compared to today's near uniformity.

    13. Anonymous Coward
      Anonymous Coward

      @Herbert Meyer - Re: not the terminal, the punch card

      You're one of us! God bless you!

    14. John Savard

      Re: not the terminal, the punch card

      And here I was going to mention the 72-column limit for languages like FORTRAN, and what do I see but the first commenter has beaten me to it!

      However, this does not mean that Linux Torvalds does not have a point, because not many people are using Linux with 3277 display stations hooked up to their computers.

    15. Daniel von Asmuth

      Re: not the terminal, the punch card

      The punch card is getting obsolete, it's the printer that does it. Line printers used to print 136 characters wide, but today we mostly use laser printers and to get that many characters you have to print in landscape orientation, while portrait remains the default.

    16. A.A.Hamilton

      Re: not the terminal, the punch card

      Not to forget the technique known as the 'floor sort':

      During the (Queensland) summer of of 1963/64 I wrote a programme in FORTRAN for the optimal design of liquid/liquid heat exchangers, At that time the availability of mechanical punches was about zero so I had to hand punch the cards. There were 3 trays, each about 80 to 100 cms long, so I was not going to advance that wretched hand punch all the way to column 73 to add the sequence numbers. On my first entry to the newly built computer room I discovered that a freshly washed floor is very slippery and that a floor sort completes very quickly. I commend the lesson to those with long enough memories.

    17. swm

      Re: not the terminal, the punch card

      The 72 character limit was due to the fact that the IBM 704 could read only 72 columns. Many IBM card applications used all 80 columns.

    18. Missing Semicolon Silver badge

      Re: not the terminal, the punch card

      And the IBM/Hollerith punched card (expanded to 80 columns in the 1920's - go check Wakipedia) is 7 3/8" by 3 1/4". A size derived from the "Large Legal Tender Note" used in the USA in the 1850's.

      80 columns is like 4 ft 8 /14 in standard rail gauge - that size is set by the width of 2 horses, side-by-side.

  2. Stumpy

    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.

    1. LucreLout

      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.

    2. katrinab Silver badge

      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.

      1. Tom 7

        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.

        1. Arthur the cat Silver badge

          katrinab is correct, it's about ease of reading. Manual typesetting is long gone except for hobbyists.

          From Bringhurst's The Elements of Typographical Style:

          If the type is well set and printed, lines of 85 or 90 characters will pose no problem in discontinuous texts, such as bibliographies, or, with generous leading, in footnotes. But even with generous leading, a line that averages more than 75 or 80 characters is likely to be too long for continuous reading.

          One can argue that vertical spacing in code makes it more like a bibliography than running text, but even then the line width should be restricted otherwise, as katrinab says, it's difficult finding the next line. Unless your text background has alternating green and white lines like old school line printer paper.

          1. Roland6 Silver badge

            > Unless your text background has alternating green and white lines like old school line printer paper.

            Seem to remember there was an editor that did use alternating line colours - made things a lot easier to read, particularly when the lines contained a lot of whitespaces - so the eye could more easily match the code on the left with the comment on the right.

            There are times when this would be useful in office programs - the number of times I've had to highlight a line, just so that I can follow it across repeated horizontal screen scrolls.

            1. Robert Carnegie Silver badge

              I thought coloured lines was an option in Notepad++, or maybe Microsoft Word. Checking documentation, Notepad++ does seem to have an option to highlight the line that the cursor is on, but that's different.

          2. Julian Bradfield

            Anybody who produces printed documents should read Bringhurst. Not that he's perfect, but it's the best, and concisest, book I know.

          3. Anonymous Coward
            Anonymous Coward

            plenty years ago my local printer/publisher agreed with Tom 7

          4. Ken Hagan Gold badge

            I feel obliged to point out that I'm reading both of you on a display that is putting well over 100 characters of your text onto each line. (And that's even with the apparently-internet-default stylesheet that discards the left and right thirds of my monitor.) It doesn't seem to be a problem.

        2. Anonymous Coward
          Anonymous Coward

          > 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

          I don't think typesetters ever held type between finger and thumb (too much risk of dropping the lot) - they just slide it off the composing stick into the frame.

    3. Pascal Monett Silver badge

      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.

      1. Anonymous Coward
        Anonymous Coward

        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.

        1. Steve Knox

          A limit is not going to stop the willy-wangers; they'll just find another excuse to shove their willy in your face.

        2. Anonymous Coward
          Anonymous Coward

          @AC - Only 512 character lines ?

          And you endure this humiliating limitation ? You have no spine! Why not go with 4 screens in one horizontal row as one single display with the resolution of your choice ? Any office chair these days have rollers so you can be way more productive.

          As for the old age I can tell you this: getting old is not fun but it prevents you from dying young.

      2. Roland6 Silver badge

        The limit is convention and portability across devices and output formats, remember most people like to use fixed spaced fonts like Courier, 80 characters at 10 or 11 point fits nicely across an A4 portrait page.

        Looking at what Linus is saying it seems that he is saying, it is okay for some lines to be slightly over 80 characters, but he isn't encouraging the usage of lines of over 100 characters.

        Basically the problem we have is the verbose nature of many system calls making it hard at times to put much on a single line.

        Other than older card-based languages such as Cobol, languages such as Algol-60 and its derivatives and successors don't actually care about line length - the preprocessor strips out the characters inserted to make the programme human readable.

        1. Anonymous Coward
          Anonymous Coward

          "Basically the problem we have is the verbose nature of many system calls"

          Actualy most linux system calls are pretty terse in both name and parameters, its the language libraries (particularly with Java) that seem to have verbal diarrhea with method names such as addObjectToListThenDoSomethingFunkyReturningMap() etc.

          1. teknopaul

            Absolutes, like MAX 80, lead to crazy code.

            Somebody told a co-worker, 10 lines per method was MAX. He split everything, no matter the logic, even a switch with more than 10 cases, and naturally, all these methods need names. Ended up worse even than your example.

            He thought he was "functional programming".

            What will we do, when Linus stops dropping sense into such conversations.

            1. Robert Carnegie Silver badge

              I think I once was in a programming team instructed to keep programs to two sides of A4 paper and functions to 1 side; any longer and we were supposed to split it out into sub-routines. But this wasn't enforced a lot, thank goodness.

            2. Vometia Munro Silver badge

              I remember having to do something with some code from a well-known vendor that was written in a similar style. It seemed to mostly consist of functions whose purpose was to call other functions. It was very leggy and tedious to follow, and probably hard to debug as it was so difficult to get an at-a-glance sense of what any part of it was doing.

              I've learnt not to automatically blame the programmer, though, as this was the same time I started to get some absurd design impositions from above. Some were perhaps poorly explained, others were just fundamentally bad ideas and I quickly stopped cursing the poor chap whose project I had to take over. That's not to suggest I made no gaffes of my own as I have plenty of real horrors to my name but it seems that at least some of the more pervasive examples of unpleasantness are courtesy of a manager who didn't understand coding and/or project management.

    4. Tom 38

      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.

      1. druck Silver badge

        88 is just a number, 13 is just a number, they are all just numbers.

        Numbers have no race, no religion, no politics, no superstitions.

        1. teknopaul

          except 23

        2. Martin-73 Silver badge

          42 character lines are the answer. the ULTIMATE answer

          Mine's the one with the towel in the pocket.

      2. zuckzuckgo Silver badge

        > "88 is a white supremacist hidden number"

        No, 88 is how fast you have to drive your DeLorean (or maybe a Tesla) to go back in time and correct your comments. It always takes me more that 10 min to notice errors.

  3. Anonymous Coward
    Anonymous Coward

    Code... WHO CARES!

    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!!!

    1. AndyS

      Re: Code... WHO CARES!

      Did AManFromMars somehow manage to mate with Bombastic Bob?

      1. Doctor Syntax Silver badge

        Re: Code... WHO CARES!


      2. Anonymous Coward

        Re: Code... WHO CARES!

        Welcome, magniloquent marvin...

      3. bombastic bob Silver badge

        Re: Code... WHO CARES!

        (the way you mention me, I must be living rent-free inside your head...)

        Limiting to 80 columns of 'actual code' works well if you use a lot of per-line comments, maybe indent the comments to column 80 so they line up. But yeah that makes the lines longer, but you'll still be able to view all of the code within that 80 columns and scroll over for the comments if your display is too narrow.

        And while you're dong that, use 2-character indents (not 8), with NO hard tabs, so that excessive indenting isn't the cause of going past column 80. Solves EVERYTHING!

        (you're welcome, heh)

  4. davcefai


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

    1. Anonymous Coward
      Anonymous Coward

      @davcefai - Re: Disappointed

      Yeah, he seems to be getting softer with everyday. It's like he no longer cares about us.

    2. EnviableOne

      Re: Disappointed

      TBF there was a godsake, but its far from his famous expletive led tirades at anyone sayiung but security...

  5. Anonymous Coward
    Anonymous Coward

    Restrictive hardware

    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.

  6. Anonymous Coward

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

    1. Teiwaz

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

      Well, I don't want to have to program code that looks like the intro text to Star Wars.

      Also modern webpages are a bollocks and not the best exemplar.

      1. Robert Carnegie Silver badge

        Star Wars intro code editing would be awesome. The drawback is the time it takes to load the file...

    2. Anonymous Coward
      Anonymous Coward

      NO! Right justification is the only way to go. I am tired of a world dominated by you lefties! And everyone knows that mail-in ballots are just a scheme to spread COVID!

  7. John H Woods Silver badge

    I agree ...

    ... 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 ...

    1. twellys

      Re: I agree ...

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

  8. Andy00ff00

    I used to feel the same.

    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).

    1. Snake Silver badge

      Re: I used to feel the same.

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

      1. Anonymous Coward
        Anonymous Coward

        Re: I used to feel the same.

        It is a useful perspective. However, as another blind programmer, I can't say I agree. On tabs versus spaces, I have set my speech software to report indentation with differently-pitched tones. The higher the pitch, the more indented is that line. This works with equal usefulness on lines with spaces, and I use those exclusively. On line length, I actually prefer my lines longer. The reason for this is that both speech and braille output are single-line only. In order to check what the previous line is, I have to move up, read it, and move back down. Having a complex expression split across eight lines does not help me because I may have to scroll up and down to keep track of it. Not that I see that very often, but I'm all in favor of disposing of the length limit. I think it comes down to different preferences, even for people using similar uncommon tools.

    2. AndrueC Silver badge

      Re: I used to feel the same.

      Also a lot of older programmers (like me) tend to use larger fonts. Now granted 80 characters is too restrictive but where I work we go with 150 because that's about all I can fit across a single screen. I can only assume that Linus can afford a much higher resolution monitor than me along with a large enough desk to fit it on.

      I agree that splitting lines can impact readability somewhat but having parts of a line completely off screen impacts it far more. It does no good for my productivity if I have to scroll both vertically and horizontally to browse through code.

  9. Duncan Macdonald

    Excessive complexity

    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.)

    1. A.P. Veening Silver badge

      Re: Excessive complexity

      I am by now used to 100 characters per line of source code (RPGLE), but otherwise I completely agree with you. In a far past I put some small C-programs with source on the internet and the most often received comment was that it was legible, something of a revelation to some C-programmers.

      SPOILER: As a COBOL-programmer, I am used to legible source, if it isn't, the source is not ready for maintenance, leave alone production.

      1. Robert Carnegie Silver badge

        Re: Excessive complexity

        I agree that what you're used to is what you're used to, although in my case that's usually around 70 characters page width to be ready when I need to use the Printout Fairy to magically reveal all the baffling bugs and typos.

    2. James Hughes 1

      Re: Excessive complexity

      Whilst EXCESSIVELY long lines can be a pain to follow, the 80 character limit makes code harder to follow because you were forced to split it when it really didn't want to be logically split. 100 seems sensible, I can comprehend lines of that length.

    3. Filippo Silver badge

      Re: Excessive complexity

      "A well written program is easy to follow - not written like a contender for the obscured C contest."

      I sometimes find myself having to argue with people who believe that being able to express a complex recursive algorithm in a single line is a mark of distinction and elegance, and also why call a variable instance_counter a function createUniqueKey when "ic" and "cruk" will do? Screw them.

  10. Greybearded old scrote Silver badge
    Thumb Down

    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.

    1. Jay 2

      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.

      1. A.P. Veening Silver badge

        My terminal windows are usually 132*27, but the code part of source lines should not exceed 100 characters in length (without line breaks). For legibility, parameters in calls can be (and usually are) limited to one per line.

    2. Steve Graham

      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?

      1. Roland6 Silver badge

        >green on black

        Those who wish to do different, DEC (and others) did offer amber screens, so amber on black and vice-versa are also options.

        1. Vometia Munro Silver badge

          I think amber became popular with terminals for the same reason the green lighting on car dashboards was replaced with amber in that it was less tiring to look at. Or something like that, anyway.

          I have a VT320 in the garage and without checking I *think* it's green on black, but amber seemed to be the more common option, with B&W coming a distant third, albeit just based on my own experiences. Most of the VT220 clones were green, though.

          My personal choice for coding (and email and... etc) is still green-on-black. I find I'm more fussy about the way the font looks than the exact colour scheme, though. But evidently not fussy enough to remember offhand what's my current preference.

          1. hoopsa

            I've got an old Audi in the garage that uses red lights on the dashboard at night; I presume it's meant to be less tiring or at least allows you to play U-Boat commander. I've got a new Audi that eschews all of that in favour of full-colour LCD dials that become slightly dimmed versions of themselves at night, so I guess whatever the reason was for the red lights, the thinking has gone out of fashion.

      2. JohnG

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

        Maybe VT340, for colour.

    3. the spectacularly refined chap

      Now the anachonism that really makes me laugh is the preference for having the terminal emulators look like a 1980 green on black screen.

      There are some good reasons for light on dark on screen, though. In the old days it minimised the effect of any screen flicker, both consciously and subconsciously. The other effect is relevant even now in that it reduces the simple amount of light shining in your face all day. Reading on screen is fundamentally different to reading on paper in that the screen is its own light source: treating it as if it was paper is a non sequiter.

      You'll find that many text editors that default to dark on white are not really a white background anyway - more grey90 in X11 speak. Even that subtle reduction in brightness noticeably reduces the amount of glare in your face and reduces eyestrain, and don't forget your eyes have better resolution when your pupils are more open.

      I recall reading some study that had been done into this perhaps 30 years ago that concluded the most comfortable colour combination was actually yellow on blue, but like most such studies based on users and actual data it was completely ignored. Perhaps 15-20 years ago I started configuring my terminals and editors to cream on dark blue in response and definitely find working on anything else does get tiresome more quickly. I also tone down the syntax highlighting in my editor to just subtle changes of hue rather than abrupt changes of colour. The only change in font is to italicise comments. I find the default highlighting settings in many editors is almost designed to distract as opposed to allowing you to focus on the code.

      1. Vometia Munro Silver badge

        I recall reading some study that had been done into this perhaps 30 years ago that concluded the most comfortable colour combination was actually yellow on blue

        I wonder if that study was around the same time as the Amstrad CPC? The description of yellow-on-blue immediately reminded me of the presentation of Locomotive Basic using the CPC's chunky font and that colour scheme. Looked pretty space-age compared to my Dragon's rather Brutalist ALLCAPS font in washed-out greeny-black on washed-out green.

      2. Danny Boyd

        >"I recall reading some study..."

        Borland probably read this study too.

      3. SloppyJesse

        "the most comfortable colour combination was actually yellow on blue"

        Word for DOS? Or WordPerfect? Seem to recall one of them had a blue background.

        1. someone_stole_my_username

          IIRC both Word and Wordperfect for DOS used white-on-blue as the standard color scheme.

          Or green/amber-on-black when using MDA/Hercules. ;-)

          1. J.G.Harston Silver badge

            As does the Soviet UKNC/Elektronika. I've been doing a bit of programming on it, it also defaults to smooth scrolling!

      4. Adrian Midgley 1

        Resolution and aperture

        Short-sighted people mostly know that looking through a pinhole brings more distant objects into focus. In eye examination that's a way to distinguish refractive errors from other losses of resolution (bearing in mind that some people cant read even if they hadn't left their spe tacles behind)

        Pinhole cameras are famously in focus at all distances,

        Camera (etc) lenses begin to lose definition due to diffraction through an aperture when the aperture gets more comparable to the wavelength of the light.

        Hence Ansel Adams at all could call their group f60 with their 10*8 cameras (which use long focal lenses) and I have to be wary toward f/22 with a 35mm camera.

        The good eye sees sharper with a small pupil.

        Bad eyes, with central cataract, less so, and all eyes need light.

  11. Anonymous Coward

    The real reason for fairly small line lengths

    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.

    1. AndyS

      Re: The real reason for fairly small line lengths

      > 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?

      1. Martin Gregorie

        Re: The real reason for fairly small line lengths

        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.

      2. Roland6 Silver badge

        Re: The real reason for fairly small line lengths

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


        Linus is having a problem with lines that are 80~100 characters long. So only a few characters need to be wrapped around.

        I suspect his problem is that if you have a lot of these lines - with only a few characters over 80, it gets time consuming to reformat to do a neat word wrap. Since many programmers only produce write-only code they see the effort necessary to improve readability as a waste of time.

        So basically, Linus's problem is the tool he is using: source code-editors need to incorporate some basic word-processor functionality so that they can intelligently wrap code.

        1. bombastic bob Silver badge

          Re: The real reason for fairly small line lengths

          "Since many programmers only produce write-only code"

          yeah, THERE's your problem...

          Seriously I came to the conclusion a long time ago that I might be "that guy" having to maintain my own poorly written/documented code, so it was in my OWN best interest to make my own code readable by non-insiders. Because in 1 or 2 years' time, I'll NEVER remember why I did stuff 'that way'.

          As pointed out earlier, limiting line lengths often helps in readability as well. But when you include per-line comments in that line length restriction, limiting to 80 columns is too restrictive.

    2. 9Rune5

      Re: The real reason for fairly small line lengths

      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.

    3. tim 13

      Re: The real reason for fairly small line lengths

      You say this, but the Register is formatting your comment at 132 characters wide and I can read it fine...

    4. Anonymous Coward
      Anonymous Coward

      Re: The real reason for fairly small line lengths

      Mind you , you can use language features to go too far the other way with statement/line lengths and strive the make them so short that they become virtually unintelligable except to the initiated. Hello Perl, I'm looking at you.

    5. Ken Hagan Gold badge

      Re: The real reason for fairly small line lengths

      But lines of code (unlike your paragraphs, which nevertheless I find quite readable at well over 80 characters per line) typically don't extend all the way to the right hand side and when they do it is usually really helpful to the reader to see that they are a single long line rather than two short ones.

    6. Adrian Midgley 1

      Re: The real reason for fairly small line lengths

      Findings which apply to people in general may apply less to programmers, the set of attributes that gives aptitude may imply capability to handle longer lines than average.

  12. Anonymous Coward
    Anonymous Coward

    This might be a mistake...

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

  13. dajames

    Fixing the wrong problem

    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.

    1. Martin Gregorie

      Re: Fixing the wrong problem

      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.

      1. Adrian Midgley 1

        Re: Fixing the wrong problem

        Piping into less is super, if you are going to read it on screen.

        Less so if it is to be piped on into something else - sed or wc eg

    2. James Hughes 1

      Re: Fixing the wrong problem

      Odd, I find longer lines much easier to read and comprehend than split lines. Especially when that split has been forced by a specified line length and may not be particularly logical.

  14. smudge

    It won't print past column 80!

    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.

    1. Anonymous Coward
      Anonymous Coward

      Re: It won't print past column 80!

      Hardware knowledge IS important for coders, buggers and de-buggers.

  15. Dwarf

    None of this is a new problem

    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.

    1. Roland6 Silver badge

      Re: None of this is a new problem

      >132 column devices

      Years back we used 80 column devices and switched to 132 column line printers. Most of the ASM programmers continued to use the first 80 columns as before, but used the additional 52 columns for a more informated commentary on the code.

      For new programs, the pseudo code was simply tabbed to the right and the actual code inserted on the left.

      It is notable that Linus is asking for up to 100 columns rather than going with the historical 132.

      1. Dwarf

        Re: None of this is a new problem

        I've never really thought about "why 132 columns" before, but as its not multiples of 40 or 80, then I'm guessing that its related to the size of paper available (probably in the US?) and how many fixed width character blobs would fit in the space.

        Although when you think a little more about this and the need for customisation of the ordinary roles of dead tree to add sprocket holes, tear lines for a page and alternative green and white stripy bars, then it makes it you wonder why they didn't go for 120 or 160 column as the page shape could presumably also be changed during the preparation of the fanfold paper pack.

        Or is it actually 120 columns with 12 extra columns for some line number prefix type arrangement ??

        Interested in this topic suddenly invoked after several decades not worrying about it.

        I found an answer ..


        1. J.G.Harston Silver badge

          Re: None of this is a new problem

          It's also weird as it's not any multiple of pixels. Most printers and terminals could switch between 80 columns and 132 columns, and you can't even get a mathematical explanation such as something like 80x8pixels divided by 7 pixels gives 91x7 pixels, or 106x6 pixels, or 128x5 pixels. There must be some mathematical justification for 80 x K = 132. K is very close to 5/3, that would give 133 characters, but why 5/3? 800 pixels gives 80x10 and 133x6 which is a 5/3 ratio.

  16. codemonkey

    I'm always surprised by...

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

    Tech evolves. Try it :)

  17. keithpeter Silver badge

    cat <somefile> | grep -B 1 -A 1 PATTERNS #?

    "They cause problems for things like 'grep' both in the patterns and in the output, since grep (and a lot of other very basic unix utilities) is fundamentally line-based."

    See title

    Ah, my coat.

  18. FelixReg

    It isn't just code that can be wide

    Comments are what can really stretch out a line of "code". Most comments are *so* much nicer when they are (column aligned) to the right of the code they talk about.

    People put multiple windows of code on-screen at the same time?!? Egad. If I ever did that, I'd just hang the other code on another screen. Problem solved. It's 2020, people. If you're a programmer you can spring for $2000+ in screens, no problem. Cover your frigging walls with a 75" TVs in 4k mode or something. Jeez. You don't need to run CGA emulators to save ASR-33 paper rolls and punch cards when you're on a multi-core, killer-GPU, 11-teen Gig super-computer.

    Tossing my CGA board and expanding to a 134 character wide VGA blasted me with a feeling - exactly the same feeling I had when moving from an assembler requiring names no more than 6 characters to one that allowed a massive 8 characters per name. Wonderful feeling of liberation and freedom.

    Linus is 20 years late. Good for him!

    1. Anonymous Coward
      Anonymous Coward

      Re: It isn't just code that can be wide

      >>It isn't just code that can be wide .........................

      I have wide balls .

      1. CRConrad

        Re: “I have wide balls ”

        Yeah, right, Senator Craig, that's why you have such a wide stance.

    2. AndrueC Silver badge

      Re: It isn't just code that can be wide

      If you're a programmer you can spring for $2000+ in screens, no problem.

      That depends who you work for. In 30 years of programming I've never worked anywhere that would spend that kind of money on me. And in any case - what about the rest of the team? £2k+ per seat is a very expensive way to run a team of programmers.

    3. Anonymous Coward
      Anonymous Coward

      @FelixReg - Re: It isn't just code that can be wide

      Yeah but you don't tell the story of your life on a line at the right of the code.

    4. Zwack

      Re: It isn't just code that can be wide

      Comments should be written in pen on the punch card. What sort of person goes to the trouble of actually punching their comments into separate cards.

  19. gnasher729 Silver badge

    80 columns may be more readable than 120 columns - but a line of code split over two lines is much much less readable than one line.

    Just checked: My iMac displays 330 characters per line in Xcode in the normal font, and 250 characters in the large font I prefer.

    1. J.G.Harston Silver badge

      My copy of StrongEd defaults to 1024 characters per displayed line.

  20. juice


    While we do have coding standards where I work, there isn't a hard limit for line lengths. And with my dev environment, I could potentially go up to about 180 characters a line.

    But that'd be silly.

    Generally I tend to stick to around 100 characters as a rough "maximum line length", with occasional stretches to 120 if it aids readability.

    E.g. when writing comments, the former of these arbitrary examples looks better to me

    // I generally only tend to go past 100 characters when it's a comment which would look silly when broken into multiple lines


    // I generally only tend to go past 100 characters when it's a comment which would look silly

    // when broken into multiple lines

    In general though, all my code formatting is driven by a single key question: does it help to make the code easy to read and understand?

    I spent a chunk of my formative years at the Perl coal-face, carving out large chunks of "clever" code which could do a zillion things in a single line, which generally looked like "checksummed line noise" (to quote an old description of Perl).

    These days, I've come to the conclusion that life is far too short to spend time reverse engineering overly complex lumps of old code to figure out how it works...

  21. Anonymous Coward
    Anonymous Coward

    Circumstances Alter Cases.....

    My book cipher uses 40 character lines (well 41 if you include the UNIX./Linux EOL)....and all this because El Reg displays 80 column lines VERY BADLY!!!!!




































    I know, I know....private ciphers (and book ciphers in particular)....are so.oo.oo.oo weak!!!

    1. Ken Hagan Gold badge

      Re: Circumstances Alter Cases.....

      Can you reduce that to 36 please? My mobe screen isn't as wide as yours.

  22. Eeep !

    Proportional spaced fonts might be a better solution

    These days isn't it about keeping code to a practical width to read on many monitor sizes when comparing code side-by-side?

    Actually I'm surprised the suggestion isn't to use proportional spaced fonts.

  23. Version 1.0 Silver badge

    32 character limit in future?

    I set my VT100 up to run on 132 characters/line for a long time, eventually I discovered that I needed glasses and went back to 80 characters. The 80 character limit was readable on every terminal - but these days we all use phones, maybe we should knock the line limit back to 32 characters?

  24. Zwack

    But I was going to build a card reader...

    I mean I have a bunch of 80 column cards, I know Fortran 77...

    And now Linus is against me.

    I HAVE to do it.


    80 column is ancient

    The last time I was limited to 80 column lines was when I was programming the Commodore 64.

    No sane person would limit lines to 80 columns.

    Often I do use 80 column lines for code, but that is then where the comment starts.

  26. martinusher Silver badge

    Somebody's bought a new computer....

    Programmers who own the absolute latest and greatest hardware are a menace to all who have to deal with their output. I'm saying this as someone who's had to be the clean up crew on more than one occasion -- you always get issued with those clever sods who really understand the minutia of expression parsing and so pack a small function's worth of code into one giant line which 'obviously' works.

    If you've ever come across 'shrouded source', a method of distrbuting commerial applications in the early days of Unix, you'd realize that a compuer can parse giibberish. A human can't. We need code to be logically laid out and easy to read, not just weks or months but potentially decades in the future.

  27. -martin-

    I definitely abuse the 80 character limit, my editor has a nice vertical line at 80 chars so I can easily see this! I do split lines when I feel it's necessary, but more generally, if the line is long - maybe a print to log or something - I wont split it (who cares if you can't see the end of the line, it's generally not interesting anyway), a big 'if' I will generally split, but at sensible splitting places, not arbitrarily at 80 characters - which often makes code ugly and unreadable.

    It would be interesting to know how many of these devices/monitors people complain about are still in existence - and would actually be upgraded to the latest Kernel -- I see so much modern stuff stuck on Linux 2.6.32, that I find hard to believe that anything with 80 char limits would end up running anything close to Linux 5... And if you're using an ancient monitor for kicks or something - upgrade or suck it up, it's 2020!

  28. DrXym

    I don't wrap on 80 characters - it's an arbitrary limit of old terminals. However I do wrap lines if I think they're not easy to read as a single line. For example a really long function with a lot of parameters. And in a lot of cases, I use the line length to decide it's time to rewrite the code, e.g. does that function really need all those args or should I refactor the function into two or three that only take a subset.

  29. JBowler

    What? Still storing the formatting with the code?

    It makes absolutely no sense to store the pretty-printed code in a source management system and it makes absolutely no sense to insist that your, or my, favorite way of pretty-printing C is any better than anyone else's. It's like storing spreadsheets in US "letter" paged PDF files.

    It made no sense in the '80s either. At that time I was writing code on Aegis with the "pad" which limited lines to 1024 characters, but no one had got round to writing a decent source management system that simply stored the syntactically parsed code, tagged with all the extensive comments we write, with a "check-out" that formatted it according to the particular programmer's pecadillos. Some of the guys in the same company did write an editor which simply formatted the code on the fly. Of course that's the way BASIC worked anyway, at least in the early '80s.

    While he's at it, how about getting rid of that 50 character restriction on the first line of a GIT commit message?


  30. hayzoos

    It's all really a single line anyway

    A line break is nothing more than a character or two <line feed> and <carriage return> whose terms go back to typewriters and represent actions for the platen which MS traditionally more closely mimics. The closely related matter of whitespace be it spaces or tabs or other are also only characters. It is quite possible in many instances to strip them all out and have a machine successfully process the result. Some of computer languages' syntax requirements are actually imposed for more readable code. If your were to view this it would resemble a single long line. It is also quite possible to add them back in in any way you wish to view the source as you wish. It is quite feasible to intelligently and in an automated fashion to line break / wrap in a language's context making for the most readable code. It is also feasible to have multiple line break / wrap styles defined and switch at will to suit different desires, needs, contexts, logics, expressions, etc.

    I always found traditional GNU tools' line based actions to be overly limiting. Not quite enough to rewrite them though.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like