49 ms·

But no, 80-column terminals in 2020 isn't “reasonable” any more

• nathan_long 6y ago
  On my 15-inch MacBook, I have a full-screen terminal running tmux, split down the middle with Vim in the left pane and a shell in the right pane. At the smallest font size I can stand in decent lighting, I can get 88 columns in the left pane. Usually I want the font larger. 80 seems good to me.
• jftuga 6y ago
  I guess his new AMD CPUs can now handle the wider columns! :-)
• Aloha 6y ago
  I started using a 132 Column wide terminal about 15 years ago, then I increased the vertical size so its 132x25, then x30, then x40 - and for some special service stuff I'll make it even bigger yet.
• TazeTSchnitzel 6y ago
  I spend a lot of time writing code on my laptop, and while that could display two 100-column terminals side-by-side, I prefer to also be able to see other windows on my screen while having text at a size that doesn't strain my eyes.
  • catalogia 6y ago
    Even on very large high resolution screens, it's nice being able to tile that many more files on the screen. I think 'narrow' source code is advantageous no matter your display.
    • TazeTSchnitzel 6y ago
      Yes, and human eyes are bad at tracking lines beyond a certain length.
    • qchris 6y ago
      I agree with you to a degree, but one of my pet peeves about certain linters and code formatting tools is when they take something that could easily be a very understandable single line, and break it up into three or more lines because that's what the normal rules look like. As a result, sometimes a 15-20 line function ends up being over 50 lines, and I end up not being able to see the entire thing without scrolling.
      • ncmncm 6y ago
        Yes, lining up arguments in a deeply indented column is criminally wasteful. Whitespace is a limited resource, to be applied where it is useful. Splattering it everywhere leaves nothing to use to unobtrusively direct attention where needed.
      • leghifla 6y ago
        Also sometimes, long lines can more easily render the structure of the program. Like when a function is called with many/long arguments several times in a row, with varying arguments. If you have one line per call, you can easily see that it is the same function and what argument is changing at each call. If you rewrite each call as 5 lines, it is much more difficult to grasp what is going on. And when you need to change, say, the second parameter, you will see that the same call is made n times, and not forget one in the process.
• juanbyrge 6y ago
  I remember bikeshedding with my coworkers about this topic a few years back while coming up with lint settings. We ended up analyzing all current line widths and realized that something like 98% of lines were under 110 characters, so that is what we ended up using.
  • krferriter 6y ago
    I think a lot of terminals just set that as the default window width. No real reason for it, I usually snap to half the screen width immediately anyways. That turns out to about 105-120 characters width. Some people might just not resize it most of the time. Especially on Mac where efficient window management just isn't a thing.
    • winrid 6y ago
      A note on your last sentence. Once I used my Win10 laptop at an interview at Apple. The interviewer saw me drag one window the the side, snap it, and then select another window to fill in the space. He said, wow, Windows is really nice! :)
      • JoshTriplett 6y ago
        I use keyboard shortcuts for that: Win+left and Win+right will maximize a window on that half of the screen. That makes it easy to quickly have a terminal or editor on one half and something else (like a browser or PDF) on the other half, using only the keyboard.
        • andai 6y ago
          To clarify, these are built in (everyone running Windows has them).
        • winrid 6y ago
          Yeah I typically use keyboard shortcuts for them too, good point!
      • 6y ago
• kstrauser 6y ago
  I couldn't agree more. Our company standard for Python line length is at 99 characters because that seems like a nice balance between wide enough to show more information, but narrow enough that it tiles well. I think it's much worse for readability to have narrow, tall blocks of code that you have to scroll around in more.
• wilg 6y ago
  Many programmers are averse to line wrapping plain text files (especially source code), which has never made much sense to me. There's great support for it in like every editor.
  • catalogia 6y ago
    Editors support it fine, but personally I find the result aesthetically unpleasant no matter the editor.
  • serf 6y ago
    linewrap is aesthetically and logically jarring when you're debugging code 'by shape'. peaks and valleys between functions and such are a huge aid visually -- line wrapping makes visualization of source code harder for myself, personally.
    • lelandbatey 6y ago
      That's only a problem if you're using a line-wrap method which doesn't account for indentation and just blindly wraps (which yes, is awful). If you want to have nice indentation aware plain text line wrapping, your text editor almost certainly supports it. If you use vim, look into the "breakindent" option. If you use Emacs, you can use the "adaptive-wrap" package with a configuration like this: ;; Indentation of softwraped code (use-package adaptive-wrap :ensure t :init (defun my-activate-adaptive-wrap-prefix-mode () "Toggle `visual-line-mode' and `adaptive-wrap-prefix-mode' simultaneously." (adaptive-wrap-prefix-mode (if visual-line-mode 1 -1))) (add-hook 'visual-line-mode-hook 'my-activate-adaptive-wrap-prefix-mode))
  • themodelplumber 6y ago
    In my experience, line wrapping makes line numbering uglier and less intuitively useful. This impacts line operations. I agree with Linus in some ways, but I think he's also repping a broad-front executive-style decision rather than a really nuanced one. And the details can really impact the preference in a case like this.
  • 6y ago
• alex_young 6y ago
  Isn’t there some merit to the notion that long lines are typically either overly verbose or mentally challenging to understand?
  • kstrauser 6y ago
    In APL, sure (at least for me). In most common languages today, using meaningful variable names, it's pretty easy to have wide but readable lines.
  • colechristensen 6y ago
    Splitting one line into many because of character limits can also make an action overly verbose or mentally challenging. In some cases, unreasonable gymnastics needs to be done to get 80 character lines, turning good variable and function names into shorter worse ones or adding functions just to hide characters.
    • Normal_gaussian 6y ago
      most languages support simply adding "visual" newlines in the middle of a "logical" line; I tend to do this to improve readability - could this be done to avoid your long lines?
      • colechristensen 6y ago
        Sometimes, but not always. I often do it too to improve readability, but it doesn't always actually improve readability. Sometimes it takes something which makes logical sense to have in one line and arbitrarily breaks it up in awkward spots over several lines. If you squish code into 80 characters wide, you lose vertical density, making a set of actions more difficult to understand by separating steps.
  • isoskeles 6y ago
    I think so, but it's still inconvenient when a length limit applies to something reasonable. Applying a short limit to solve the problem of any single line becoming overly-complex will have other consequences. Most obviously, it's going to push some developers into bad habits re: naming things, where variable names that have more meaning than a counter become single letters.
• wozer 6y ago
  I hate it when zealot coworkers reformat code to 80 columns. It almost always gets much less readable in the process.
  • rantwasp 6y ago
    agree with them that there should be a limit and set it to 120
    • wozer 6y ago
      yes, 120 seems reasonable
  • rbanffy 6y ago
    God made the VT52 with 80 columns for a reason.
• winrid 6y ago
  This!! At <current_company> people are insisting we use a max of 80 columns for the linter. It's a huge pain compared to 100 or 130 columns and doesn't help readability. Everytime someone tries to argue for it I want to suggest we swap their Mac for a Commodore 64...
  • u801e 6y ago
    Well, the C64 had a 40 column display width for the BASIC interpreter, but I think it was possible to have statements that wrapped and could go up to 80 characters (I may be wrong about that though).
    • winrid 6y ago
      The more you know! Thanks.
      • saalweachter 6y ago
        The VT100 is commonly considered the origin of the standard terminal size, although I've seen pedantic historians take it several steps further and sideways.
    • ken 6y ago
      Up to 79 characters, including the line number. Interestingly, this was basically (ha) an editor limitation, not a language one. You could use 2-letter abbreviations for the language's reserved words to cram more code into the same space. The programs were stored (IIRC) in tokenized form.
  • krallja 6y ago
    80 columns on a C64 is a real reach. You need special hardware (or horribly slow & fuzzy text) for that.
    • u801e 6y ago
      The C128 did have a 80 character mode[1]. [1] https://www.c64-wiki.com/wiki/Commodore_128 https://www.c64-wiki.com/wiki/Commodore_128
• shockinglytrue 6y ago
  Typical ill-considered comment from Linus, and surprising for someone getting on his years. Column width is an accessibility issue. I'm barely in my mid 30s and the average font size has been steadily creeping, maybe 1.5 pts per 5 years. I could tolerate 132 column files today, but by the time I'm 50 there is no way this will work, regardless of screen size
  • okareaman 6y ago
    I'm 62 and don't normally wear glasses, but reading glasses have become a big part of my life. I use 1.0 to look at my big screen, 1.75 to look at my phone and always misplace them somewhere.
    • dboreham 6y ago
      Head to Costco and buy three three packs of the diopter strength you loose. It'll take a few years to loose 9 pairs and if you bust them out of the pack when a pair is lost then you always have a scratch free pair.
    • falcolas 6y ago
      As "nerdy" as they look, the CliC brand readers (that separate magnetically at the nose, and that wrap around the back of your head with a solid band) are remarkably good at sticking with you as you move around in the day. 1.0's at the computer, 1.x around your neck. Sadly, they don't make them with anything under 1.25.
  • mikelward 6y ago
    Can't you enable line wrapping in your editor?
    • knolax 6y ago
      Line wrapping is an abomination.
      • mikelward 6y ago
• briandilley 6y ago
  I wonder how Linus feels about tabs vs. spaces (I didn't read the entire post, so maybe he addressed it?)
  • mariocesar 6y ago
    > And yes, we do use wide tabs, because that makes indentation something you can visually see in the structure at a glance and on a whole-function basis, rather than something you have to try to visually "line up" things for or count spaces. That is what he says
  • saagarjha 6y ago
    The kernel uses 8-space tabs.
    • ccmcarey 6y ago
      How do you mean 8 space tabs? Are tabs not single characters \t?
      • ordu 6y ago
        You can customize your text editor to show them as any number of spaces. Mostly people prefer tab-stops at each forth or eighth column.
        • dezgeg 6y ago
          In practice you get problems, because of the line length rule. I.e. if your editor is configured with four-space tabs and a line with one leading tab shows up in your editor having 79 characters, it will show up as 83 characters for others assuming the normal 8-space tabs thus breaking the line length rule. Not to mention that coding style may require that function calls broken to 2 lines must have the arguments aligned at the opening parenthesis. For example, breaking up foobarbaz(1, 2); into two lines would require having the second line start with <TAB><SPACE><SPACE>2); which would no longer look correct with 4-space tabs.
• u801e 6y ago
  I find as I get older that I need to use bigger fonts in order to easily read code. Based on my terminal font, I can fit two windows side by side with 90 character line lengths, but if I have 3 windows, it would go down to 60 characters (though that's not something I commonly do). I also find diffs that involve changes to shorter lines easier to read compared to ones with longer lines. I wonder what he now thinks about line length in email and git commit messages (excluding things like logs, error messages, etc)?
  • JohnL4 6y ago
    I'm sorry, if you can no longer code in a 9-pt font on a high-DPI screen, you have to quit. I don't write the rules.
  • g7r 6y ago
    Yes! The thing about line width limit in terminal isn't about display resolution and size only. As a man who prefers big characters due to conditions I always vote for lower line width limit. It is starting to get really uncomfortable on lines longer than 100-120 chars.
• stickfigure 6y ago
  The problem here is that our editors aren't smart enough to wrap code appropriately. Word processors know to wrap lines on word boundaries; a smart code editor should be able to wrap lines and indent parameters in a human-pleasing way as you drag a window wide or narrow.
  • saagarjha 6y ago
    I think most editors these days do a pretty decent job? It's not perfect, of course, but 99% of the time it's fairly readable.
    • wallacoloo 6y ago
      More generally though, there's an argument to be made that line-wrapping should be a thing your editor does as part of the rendering process -- not a thing it encodes into the actual source file. Modern languages come with excellent auto-formatters which can make the code look nice at just about any line length. What we need to do is integrate the auto-formatting into the editor (likely via a language-server) so that it can adjust to the width of the editor dynamically instead of running it directly on the files at some width that's forced to be the same for every user of the codebase in every setting.
      • williamdclt 6y ago
        We could stop storing code as text, just store an AST and let the editor parse it and render it respecting the preference of the user (I think this is a terrible idea, but also got me thinking if there's something interesting there)
        • falcolas 6y ago
          > We could stop storing code as text Why is this terrible? Syntax errors would no longer exist, it would allow editors to work directly with the AST and not text... I think this is a fine idea personally. Our current editors already try to do this - letting you work with syntax and not text - via smart completions, boilerplate templates, and syntax highlighting. Working with an AST directly is only taking it a step further (and better, it removes the reliance on context-insensitive regex based tooling in the editors).
• theonemind 6y ago
  Optimal reading width is like 40-90 characters, and if I end up with an excessively long line, often times, I’ll try to rewrite a bit, not just line-break my first thought, but use it as a creative spur to write better. Personally, I like 80 character lines. If I need more than 80 characters in a line, I treat it as a code smell.
  • RHSeeger 6y ago
    > Optimal reading width is like 40-90 characters That statement follows along the same line of thought that many people that want 80 char lines have. That it's better because "it's optimal". I have yet to see any significant study actually showing this to be true for the case of something like code. Personally, I like longer lines where they make sense, and shorter lines where they make sense. But overall, I like a line configuration that lets me understand as much as possible with one screen of lines. That's the same reason I prefer short functions, because I can understand more in the same screen space from a single function call (by the name) than I can if the same code is inline.
  • lostmyoldone 6y ago
    For non whitespace text that might be a good figure but it doesn't automatically imply that the same would be true for the full width indented text. I don't personally feel that the indentation most programming languages employ have any effect at all on my reading, unless possibly it's too narrow as code is partially read as a graphical construct. Hence limiting the length of the entire line to an equal width seems unnecessarily restrictive.
  • thiht 6y ago
    40 chars is unreadable. I have a buddy who writes all his mails wrapped at 60 chars and it's already a pain to read.
• saagarjha 6y ago
  I'm a big fan of softwrapping. Not because it's inherently prettier or something, but because the results are consistently better on more platforms because they can softwrap at what you've set the column width to be and not some arbitrary number someone thought was a good idea. (I have a similar argument for using tabs, but I digress.)
  • u801e 6y ago
    This is what Linus has said in the past regarding soft-wrapping: https://github.com/torvalds/linux/pull/17#issuecomment-5661185 https://github.com/torvalds/linux/pull/17#issuecomment-56611...
    • mekkkkkk 6y ago
      Ironic that his reply is almost unreadable on mobile because of his hard wrapping. Intentional?
      • u801e 6y ago
        Github provides an email to Github comment gateway. So he was composing his replies in his email client.
        • williamdclt 6y ago
          And his email client hard-wraps at 80 chars, because that's the standard of both Linux and Git mailing lists, because they send patches in emails. I like the irony :)
          • voodootrucker 6y ago
            > patches in emails Cringe.
            • ornornor 6y ago
              ?
• imglorp 6y ago
  Good riddance. If we pick a new suggested width, maybe it shouldn't be based on a 1928 punch card standard.
• Fiahil 6y ago
  I guess most of us, pragmatic people, agree that 80 columns is not a sane standard anymore. The more interesting question is "what would be a good default line length in 2020?" I vote for 120 columns.
  • jacobsenscott 6y ago
    Github is the new fixed width terminal, and 120 columns is about right for that. That's our standard.
  • zajio1am 6y ago
    I would say that 120 is too much - for 1920px (still widespread resolution) and split screen (2x120), one would need 8px-wide font to fit and no other borders. 8px-wide font is IMHO not enough for good readability, even VGA in 198x switched to 9px-wide fonts (from EGA 8px-wide fonts). Next natural values are 106 (for 9px fonts) and 95 (for 10px fonts).
    • Twixes 6y ago
      Few use bitmap fonts today, especially with retina displays and whatnot
  • zenlot 6y ago
    Good line length for 2020 is 80 columns.
  • kakwa_ 6y ago
    I would vote for something around ~100 with a tolerance for ~130 (CI/linter warning if between 100 and 130, maybe with a threshold limiting the proportion of lines per file in warning so that the tolerance is not abused).
• CalChris 6y ago
  I agree that 80 is too small in 2020, and hasn't been since around 80x25=2000, but LLVM is stuck at 80 columns [1]. I'd be interested to see a canvas of other big projects. [1] https://llvm.org/docs/CodingStandards.html#source-code-width https://llvm.org/docs/CodingStandards.html#source-code-width
  • truncate 6y ago
    Looking at examples, they also seem to have 2 space indents. Google C++ Style Guide also uses 2 space indents. I've never measured it, and my observation is very likely biased (as I've mostly worked with C++), but I've found 80 columns in big C++ projects often very limiting. Maybe less often now, after people are most accepting to new features; e.g type inference `auto` over `MyNameSpace::BlahContainer::const_iterator iter`.
• jofer 6y ago
  I'm a bit fan of usually wrapping at 80, but not requiring it in a linter. Do what makes the most sense for readability, but often lines significantly over 80 characters are more readable as two lines. I typically work with multiple horizontal splits open. That's part of why I prefer 80 characters. However, I really do feel that a soft break at about 80 is good for readability, and certainly easier with larger fonts.
• Arathorn 6y ago
  Fwiw, we use 120 columns for Riot/Matrix stuff (https://github.com/matrix-org/matrix-react-sdk/blob/develop/code_style.md https://github.com/matrix-org/matrix-react-sdk/blob/develop/...) - 80 is incredibly constraining for JS and JSX. The key metric is to ensure that a typical laptop can show two screens side by side, without any ugly line-wrapping. Also, any wider and you either end up having to scan a wide distance left to right (the same reasons that newspapers use columns to be more legible) - and it also helps discourage lots of nesting and cyclomatic complexity.
  • JohnL4 6y ago
    Interesting. I, too, use 120. It makes diffing code easier.
  • delaaxe 6y ago
    I've found 120 to be the sweet spot - it either fills a laptop screen entirely or allows 2 open editors on a wide screen.
  • whycombagator 6y ago
    Nice 120 is also what I've settled on & am used to. But I'd be equally OK, and adjust fine, with anything from 100-120.
  • JMTQp8lwXL 6y ago
    80 works fine for JSX if you have linter rules that put each prop on its own line, for when you have >80 characters of content.
• js2 6y ago
  The problem with overly wide lines is that it hurts readability because it's harder to find the next line when scanning your eyes from right back to left. Take it from the world of books: This study may be helpful: > This study examined the effects of line length on reading performance. Reading rates were found to be fastest at 95 cpl. Readers reported either liking or disliking the extreme line lengths (35 cpl, 95 cpl). Those that liked the 35 cpl indicated that the short line length facilitated "faster" reading and was easier because it required less eye movement. Those that liked the 95 cpl stated that they liked having more information on a page at one time. Although some participants reported that they felt like they were reading faster at 35 cpl, this condition actually resulted in the slowest reading speed. The Effects of Line Length on Reading Online News[1] 1. http://psychology.wichita.edu/surl/usabilitynews/72/LineLength.asp http://psychology.wichita.edu/surl/usabilitynews/72/LineLeng... For slabs of body copy, I like about 70 characters per line, but anything in the 50-80 range seems good. I also think justified text is harder to read, due to the lack of unique shapes to track on the right side of text — it's far easier to lose your place. https://graphicdesign.stackexchange.com/questions/13724/recommended-column-width-for-text-reading-digital-vs-printed https://graphicdesign.stackexchange.com/questions/13724/reco... I still often code on a 13" Macbook where I can open a pair of side-by-side windows in my editor with the dock on the side and get about 95 characters into each window. I typically code in Python and use a 4 space tab and a font legible to my 48 year-old eyes w/o reading glasses. On my external monitor, I take advantage of the extra width to open additional windows. So I dunno, still prefer 80-88 characters for coding, 100 max. The grep thing seems like a red-herring. Use grep's -A, -B, and -C options to get more context.
  • vlovich123 6y ago
    Is there any research to suggest that reading legibility of code is the same as for regular text? Unlike regular text code often has special characters & indentation to break it up, so intuitively I would assume it could support longer line lengths.
    • chipotle_coyote 6y ago
      I was wondering the same thing, yes. I'm often an annoying stickler about keeping line length for text on the web set to what a couple centuries of book design have taught us makes long-form prose more readable, but code is not prose. I try to keep multi-line comments wrapped to around 78 characters, but I'm not really too worried about code. (This invites a rant about people, usually people who use Emacs, who put hard line breaks in text paragraphs, but I'll save it for another time.)
• vjeux 6y ago
  It's ironic that he's wrapping the text of this email at 80 columns rather than letting the email reader do the wrapping based on the width.
  • ordu 6y ago
    Text and source code in a programming language are different things. Most lines in source code do not fill line from start to end. And there are a lot of almost empty lines (in terms of count of non-space characters). It is easy to navigate through this by eyes. But when you got a rectangle filled with characters it is much easier to get lost.
  • pkilgore 6y ago
    > Word-wrapping is a property of the text. And the tool you use to visualize things cannot know. End result: you do word-wrapping at the only stage where you can do it, namely when writing it. Not when showing it.[1] - Linus Torvolds [1] https://github.com/torvalds/linux/pull/17#issuecomment-5661185 https://github.com/torvalds/linux/pull/17#issuecomment-56611...
• dboreham 6y ago
  A vt-100 could do 132 columns and I've always set my terminal windows to that width.
• SparkyMcUnicorn 6y ago
  I'm hoping that one day I'll be programming in AR or VR, unbound from the limits that come with a statically positioned (and sized) screen. There's still a lot of issues that need to be solved, but I'm hopeful all the pieces will come together in a relatively short amount of time.
• cdelsolar 6y ago
  He's wrong. I can barely fit 80 characters on each panel when I split my code window into two on my Macbook Pro. Any more and I wouldn't be able to see the whole line, or would have to grow eyes that can see tiny fonts.
  • nathanyukai 6y ago
    He's not wrong, he just doesn't care for your use case. Get a monitor or don't have two terminals side by side.
    • cdelsolar 6y ago
      my use case is extremely common.
• elihu 6y ago
  I think 80 columns is a bit narrow for modern monitors, but still lines shouldn't be excessively long either, so you don't waste screen real estate on vast expanses of white space. Something in the neighborhood of 100 to 120 columns is probably about right these days.
• deleted 6y ago
  [deleted]
• alkonaut 6y ago
  Or just accept that a few lines in a code file or log is longer than the screen. Don’t use wrapping, it destroys the layout (of a log etc). Just scroll to see the rest of the line! You scroll down to see any lines that aren’t on screen, why would (occasionally) scrolling right be worse? Readability is some times worse with wrapping. If you want to answer “but my terminal can only trim or wrap, not scroll!” then perhaps that’s a relic just like the 80 wide display?
• ceocoder 6y ago
  Here is Rob Pike on 80 column limit[0], I’ve seen folks having to go through just crude gymnastics to make 80 column check for pep8/flake8 before someone inevitable disabling that chek/or add ignore check for that line. One think I love about gofmt is it does not give a rats behind for how long a line should be. [0] https://twitter.com/rob_pike/status/563801489190043648?s=21 https://twitter.com/rob_pike/status/563801489190043648?s=21
• robbrown451 6y ago
  I'm all for soft-wrapping. I sometimes cram windows side by side so I can see more files at once, and sometimes spread them out so I can see more of a file at once. I move and resize windows as the need arises. And I really don't want to spend brain power thinking about where to wrap things. I was glad that word processors made it so I didn't have to think about carriage returns after about 1981 (yes I learned to type on a mechanical typewriter), and glad I stopped having to think about it in source code around 2010.
• chj 6y ago
  In fact, I try to go even narrower, because almost every time my editor ends up with at least 3 columns. By the way, indentation with more than 4 spaces wide is why you get long lines. Don't do it.
• ridiculous_fish 6y ago
  Text has solved this problem without requiring hard line breaks at regular intervals.
• vincent-manis 6y ago
  I long ago concluded that arguments over line width, indentation, etc. are a waste of time. If I were submitting a kernel patch, I'd follow the Linux standard without complaint, regardless of my preferences. That said, the best argument on line length is “the magic number 7, plus or minus 2”, our limits on short term memory. I like to be able to comprehend a line of code (or of text) in one glance, which seems to me to be about 65 characters, ignoring leading indentation; that might well be less than about 10 tokens. With wide tabs, that might well hit something around 90 characters, perhaps. IMHO, it's not the line length that matters, but the number of tokens per line. By the way, I like to work on laptops. If anyone knows where I can get a laptop with a 43" screen, please let me know.
  • data_ders 6y ago
    ooo i love idea of tokens per line idea. do you mean distinct words per line? or conceptual objects you have to juggle in your head?
• egypturnash 6y ago
  Damn this sure is not what I expected Linus to be saying, I seem to remember a previous lengthy, swear-filled rant from him about why the Linux sources require a line break at 80 characters and why this is absolutely perfect and sensible and will never ever change and you are a moron for suggesting otherwise? I may be imaging this, I dunno.
• avodonosov 6y ago
  Optimal code line width has very little to do with monitor or window width. It's more of an anatomical restriction: the resolution of the human eye and the field of view. For example, if we had 10 meter-wide monitors we won't be able to see them entirely from a close distance. Increasing the distance will require to increase the font, so the number of characters per line we can use doesn't change much. Not so long ago I showed a piece of code on a mobile phone to a colleague, saying he should use shorter lines. He replied I need a larger display. When I opened the same code on my desktop display the lines were not fitting the editor window almost the same as on the mobile screen. (The angular sizes of a mobile phone screen and individual characters on it are approximately the same as of the bigger screen and characters on it because we keep phone closer to eyes). I currently work with a codebase where long lines are used and it is so inconvenient. When I switch to some 80-cols code it is such a relief.
  • TeMPOraL 6y ago
    Details matter. The way I'm set up at my desktop, my editor can fit ~320 columns. Which means I can fit four 80-column-wide files side by side. Three, if you account for line numbers on the margin. (I usually do two, because my code tends to go up to ~120 characters.)
    • demosito666 6y ago
      The more reasons to use narrower lines, right? I mean, I work in two files side by side 50% of the time, and with 120 chars the text would require wrapping, which is really unreadable in e.g. python.
      • jabirali 6y ago
        Personally, I prefer handling long lines via horizontal scrolling (with keyboard shortcuts) rather than wrapping.
  • threatofrain 6y ago
    You don't read code the way you read a book or long-form document, as authors generally don't optimize for vertical reading.
• zajio1am 6y ago
  Personally, i limit line length to 95 columns - 1920 / 10px wide font / 2 (horizontal split screen) is 96, minus some pixels for borders.
• jacobsenscott 6y ago
  If there so some tool everyone uses that constraints the width use that. Otherwise treat programmers like grown-ups and let them break their lines where they want. The width of a github code window is about 120 characters. That's suggested max line width because horizontally scrolling diffs during a code review is terrible. It is rare that we have any lines close to that long though.
• waynecochran 6y ago
  I'm an old programmer that still has the 80 character limit burned into my frontal lobe. But I reached an age where I don't waste anytime worrying about these things. I am surprised Linus is such whiner about this.
• DoubleGlazing 6y ago
  I think this is a subject most editors fail to address. A single line of code should be written to file as a single line - no matter how long. However, the editor you are using should be able to gracefully word wrap it depending on your settings. Most editors word wrap based on window size or some other hard setting. They should be able to wrap gracefully at a logical point in the code e.g. at a comparison operator or a dot in a function chain. Wrapped lines could be tabbed or visually flagged to let you know. In other words there should not be am ideal line length for code, but instead editors should be able to adapt to make life easier for developers. Look at word processor documents, imagine how much of a nightmare it would be if such documents had a hard limit of characters per line.
  • EsotericAlgo 6y ago
    Is it an issue of editors or of language? The amount of errors that incorrect whitespace characters cause in whitespace sensitive languages could attributed to editors obfuscating what's written to file. I think the pragmatic solution is an opinionated linter that can be broken.
  • falcolas 6y ago
    Even vim handles word wrapping well. A text editor which can't... well, it's a pretty poor text editor then, isn't it? That said, I don't know of many text editors (outside of notepad, and even that's gotten better lately) which don't offer options about how to (or not to) wrap text.
    • smabie 6y ago
      No text editor that I know of intelligently word wraps code. Vim doesn't and Emacs doesn't either.
      • bryanrasmussen 6y ago
        When I hear the word intelligently used in the context of something a computer should do I start to think that perhaps the reason it doesn't do it yet because our expectations are too wide and fickle for it to work as yet. So perhaps this is the test of AI, when it formats my code the way I want it all the time without making a mistake.
• hirundo 6y ago
  The critical viewing scenario is two files displayed side by side. This is very useful, but having to side scroll makes it less useful. So when choosing an optimal maximum line width per file, pick an optimal display width and cut that in half. And if I'm a coder on your team, please pick the optimal display width using a 12 inch 1080p laptop screen. Also, pretend that your vision isn't 20/20. Thank you. Bottom line, 80 columns isn't unreasonable.
• swiley 6y ago
  Most people consider 40 ems the maximum readable line length, that’s half of 80 columns. At least at work, I feel like my 80 column terminal is probably the only “reasonable” app as far as layout and readability go.
• thangalin 6y ago
  France named Basile Bouchon invented a way to control a loom using perforated paper tape in 1725. The descending lineage can be traced to 80-column terminals: https://dave.autonoma.ca/blog/2019/06/06/web-of-knowledge/ https://dave.autonoma.ca/blog/2019/06/06/web-of-knowledge/ In his Elements of Typographic Style, Robert Bringhurst suggests that 66 characters per line, including spaces, for single-column pages is optimal: https://dave.autonoma.ca/blog/2020/04/11/interior-book-design/ https://dave.autonoma.ca/blog/2020/04/11/interior-book-desig... What studies have reviewed code quality versus line length? Or eye fatigue versus line length? Or comprehension versus line length? Are their any studies that attempt to approach optimal line length empirically? My preference is to indent 2 spaces rather than 4, which allows a lot of code to fit within 80 columns. When and why did 4 spaces became the norm?
  • chj 6y ago
    4 spaces allows you to have manual line wrapping, for example: if (a < b || b < c || ... || d < e || ... ) Do something.
• williamdclt 6y ago
  I see a lot of people saying that 80 char is a thing of the past, but that's not really my experience: My work machine is a macbook pro 13", I rarely have a second monitor (and when I do, I tend to have my browser on it). I get 2 panes of just under 90 chars side-to-side in VSCode, with a normal-smallish font. Am I in such a minority?
  • squaresmile 6y ago
    From the comments here, I guess we are so. I have a 1080p 14 inch laptop and with Consolas at 15px and it's pretty much exactly 2 panes of 80 chars in vscode. I would increase the limit if I can fit more though and I don't mind accommodating others who prefer a higher limit.
  • fzeroracer 6y ago
    No, I currently work on a single screen laptop right now as well due to lacking the right cables to put together a multi-monitor setup. I always feel like when people advocate 'no 80 column terminals period' they're arguing from the standpoint of having never had to use anything smaller than an ultrawide resolution display or three+ monitors. Larger lines are almost unreadable on my screen and any sort of word wrapping only makes it worse, so often I'm stuck with one file open at a time slowly jumping between files. 80-column terminals as someone else brought up is an accessibility issue.
• madhadron 6y ago
  A friend of mine was legally blind. Keeping lines to 80 (or 88) characters was a way for him to be able to deal with text with a huge magnification. So keep to 88 characters, please. Not everyone has good eyes.
• mD5pPxMcS6fVWKE 6y ago
  I think the famous rule for short memory capacity (we can on average keep 7 words/numbers/objects in out short memory) should also apply here. Up to 7 words/operators per line, up to 7 lines for a function etc. are optimal.
• throw0101a 6y ago
  "Does Column Width of 80 Make Sense in 2018?": * https://news.ycombinator.com/item?id=17436945 https://news.ycombinator.com/item?id=17436945
• deleted 6y ago
  [deleted]
• camgunz 6y ago
  I’m an 80 cols person, and I admit to be low-key enraged by wide lines. I really like having lots of side-by-side editors and a terminal, and long lines bust that, and I resent what feels like a lack of sensitivity for others’ workflows in many modern tools that generate wide lines. That said, I try and practice what I preach and let my coworkers who are into wide lines (120, woof) have ‘em. I just run a formatter after I check code out, ez. Everyone should do this, online diffs should default auto format to 80 cols (but configurable), and we should put this debate to rest.
  • kstenerud 6y ago
    Why should online diffs auto format to 80 cols? Shouldn't that be up to the user?
    • camgunz 6y ago
      Sorry I ninja edited you. Diffs with wide lines don’t always fit on screens; but if you have a wide monitor, set it to 400 for all I care.
• robomartin 6y ago
  If I remember correctly, DEC, Tektronix, Honeywell, Qume and other real terminals moved to 110 characters per line in their later generation terminals. Coming from the perspective of that era I never understood the obsession with 80 characters per line. I can honestly say that I have never limited my code through such artifice, ever. I can give examples of code where artificially breaking things into 80 characters makes an absolute mess out of things. Complex table-driven state machine lookup tables and FPGA I/O definitions come to mind, among others.
• pauljurczak 6y ago
  We had only at most 72 positions available on 80 column punch cards, and we loved it! Bring back the 1950s! ;-)
• ak217 6y ago
  Can we please just settle on 120 columns as the new 80? It would make things so much more reasonable. I have to agree going wider than 120 makes things harder to read. 80, no, there is no way I'm going to voluntarily follow that standard - I will have to be forced into it, and I won't like it.
  • hinkley 6y ago
    I recall deciding quite a long time ago that I was going to do 100 columns and not ask anyone. It was with great amusement that I noticed, not very long after, that JetBrains added/moved the default gutter warning to either 100 or 120 columns. That said, I do 4 space indents and 100 columns, not either/or. 2 space and 100 is an invitation to excessive nesting over decomposition. If you insist on 2 spaces then I’m afraid I’m going to insist on 80 columns (and that you finally get off your ass and learn how to code).
• hinkley 6y ago
  If you’re going to have this argument, it’s important that you do it right. The question is not precisely “how wide can I display code”. The question is “how wide is a side by side diff?” That is the worst case scenario for code reading, and it is the one where the worst classes of errors can slip in (one where neither author actually wrote the bug). Linus answers this indirectly: you can easily diff 100 characters on a monitor smaller than his. What he says instead sounds like an invitation to suggest 200 column source code, which most definitely is a problem to diff.
  • pas 6y ago
    Using softwrap when looking at diffs seems natural. After all you already rely on tools to show you the meat of the diff, the changed lines, and preferably the tokens inline. Plus I find that most of the time I just use the default patch view, not the side by side one when doing review.
• aimor 6y ago
  I'd rather have 80 columns on a 4:3 ratio than 120 columns on 16:9. "A wide monitor is for" watching video, playing games, and putting larger diagonal numbers on the box. I miss turning one monitor sideways to nearly fit an A-sized document. And I miss those 120 extra vertical pixels from before 1080 became the standard. I think the only good and common option right now is 21:9 in a large size and resolution, you still won't get 1600 vertical pixels like with a 3:4 but 1440 is still useful and there's enough horizontal space you won't get distracted over nonsense like how many characters wide a line should be.
  • bjoli 6y ago
    I would gladly pay twice the price for a 4k 4:3 or 3:2 monitor. Even on wide displays, I rarely split top-to-bottom more than once. More vertical space would mean a lot more usable screen estate for me.
    • zapzupnz 6y ago
      So just turn a 16:(9/10) monitor sideways. Plenty of vertical space.
      • bjoli 6y ago
        Two of them next to eachother makes for 16:18 which is my kind of screen!
• Arch-TK 6y ago
  I don't get it. 80 columns was always short but it forced you to think about your code when it got too long. Contextually local variable names which go far above 10 characters and contextually local function names which go far above 20 characters are almost always misnamed. Nobody should struggle to fit at least within about 100 characters when they're focusing their code on clarity and simplicity. Obviously this doesn't mean that you should rename your buf_size variable to bsz or s. But you buf_size variable in a function called read_line shouldn't need to be called line_buffer_size and if there's only one buffer should potentially just be called size. Then there's people in this post claiming that research relating to readability of text don't apply to code because people don't read whole lines. I only have to wonder if these people have ever read code they didn't write on that same day or from a codebase they're already very familiar with. I read a lot of code, it's part of my job, I need to read the whole lines so I can verify that there's nothing horribly wrong. It makes it incredibly difficult to read expressions when they can't fit within my visual field. Yes, hard-wrapping code is not great, it should be avoided and only done with a good bit of experience, insight and awareness of how it's going to affect the code. Regularly making your code 150 lines long because your variables are repeatedly telling me information I could have just gathered from looking two lines up and because your function names are descriptions of the behaviour of the code they contain isn't a great look either. Although I still think that my least readable experience was having to read and work with code which used a 2 space indent (and an editor which wouldn't let me fix this in any way) which regularly went 10 levels deep and 100s of lines long.
• jedisct1 6y ago
  I like 128 because it’s a round number.
• nickdothutton 6y ago
  Old enough to remember 132 column line printers and using them to do code reviews. It felt very convenient.
• spion 6y ago
  Here in JavaScript land, we have Prettier and can configure the line limit to be whatever we want on our local editor and whatever else we want when we save the saved file, making this entire discussion irrelevant. Its time for more development tools to be built with individual developer in mind, adaptable to their workflow and needs. See for example https://old.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/ https://old.reddit.com/r/javascript/comments/c8drjo/nobody_t...
• SergeAx 6y ago
  I really like this wiser version of Linus. Imagine that text five years ago)
• Jaruzel 6y ago
  One of the first things I do, on every Windows box/session I use, is change the Command Prompt defaults from 80x25 to 132x50. It's about time Microsoft updated the default tbh (and also switch the default to something more modern).
• LargoLasskhyfv 6y ago
  I never understood this fetish. Using workstations with graphical framebuffers, which even had the system console in whatever was hires then, setting the system console to 132x60 in text mode on 21 inch for FreeBSD was one of the first things i did. That punchcard inspired technical limit was something to overcome, not to embrace.
• seemslegit 6y ago
  That email sure seems to be formatted for 80 columns
• 978e4721a 6y ago
  Jesus, what a bullshit. It's not about screen size, it's about reading experience. If you think that longer lines making something easier to read - try to read non-trivial book with 100 characters width.
  • dragonwriter 6y ago
    Books tend to use proportional fonts which can tolerate greater average line lengths (measured in in characters) than monospaced fonts of similar size (same em), and in any case won't have a constant length in characters line-to-line, but instead vary based on the specific test to be similar in total width.
  • makapuf 6y ago
    Books are definitely not indented, code can be up to 50% of actual text. In that case 120 columns.
• karmakaze 6y ago
  Google "common|popular|standard source max line length" 125 characters per line is the real de facto coding standard for maximum line length these days, because this is the maximum number of characters that you can see in the GitHub diff view. This used to be 119 characters, but the page layout changed. I just updated my editor to show rulers at 100, 120, 125.
• cbm-vic-20 6y ago
  I keep my VT420 in 132x39 mode, but it does take a little longer to redraw the screen at that size.
• lmilcin 6y ago
  Nothing really changed about Linux kernel that would require columns to be wider. The only things that changed are developers and their developer setups. We got better, wider monitors and we got used to using longer variable and function names. 80 characters is an arbitrary constraints that requires me as a developer to think how I am structuring my code. It also makes it easier for me to read the code as 60 characters is about perfect column width for readability.
• Avamander 6y ago
  Hot take, the same applies to Git. Description should be autowrapped to each individual's preference, some have larger screens, some smaller, some need larger fonts, some smaller. The message shouldn't have a pedantic upper limit either. Fscking autowrap it if you're using a VT-100.
• dkersten 6y ago
  I went from kinda following the 80 character “rule” to 120, to not following it at all and now back to 80. Why? Because I like to have three editor windows side by side and at the font size I’m using, going above 80 means I have to scroll and word-wrap looks unpleasant to me. Keeping lines short also helps when pasting code to instant messengers or reading side-by-side git diffs.