15 ms·

Is the 80 character line limit still relevant? (2008)

• peterhadlaw 2y ago
  yes, for split screen - e.g. two files open at once.
  • Nashooo 2y ago
    It's mentioned in the article..
  • marssaxman 2y ago
    I've got five files open on my monitor right now, side-by-side! Wouldn't be practical if the codebase used a lot of long lines.
    • rusk 2y ago
      Two files on a laptop
• aithrowawaycomm 2y ago
  One minor advantage which wasn’t so relevant in 2008: 80 character lines are much easier to read on a smartphone. This is especially true for Safari on iOS, which always seems to make bad wrapping / sizing decisions with plain text. ETA: thinking back on it, several years ago I switched from 120 characters to 80 specifically because of this. I don’t have a car, so I read a lot of code on my phone while taking public transit.
  • runjake 2y ago
    Someone else is going to be weird and want to look this up so I'll save you the trouble. Yes, aithrowawaycomm's claim about line lengths are supported by many, many different sources who recommend a 50 to 80 character line length. https://duckduckgo.com/?q=reading+optimal+line+length https://duckduckgo.com/?q=reading+optimal+line+length IMHO, 80 characters is too narrow, especially with Python, for most coding tasks so I settle more around 100 (+-20) characters. PEP-8 says up to 99 characters is okay. https://peps.python.org/pep-0008/#maximum-line-length https://peps.python.org/pep-0008/#maximum-line-length
    • o11c 2y ago
      It's worth noting that most of those studies are for body text. To make that more directly applicable we should exclude indentation, but the additional punctuation (especially commas, but unfortunately no parentheses) also affects it. Shading lines can also improve readability (this is known; the rest of this comment is speculation). It's probably not enough to simply alternating between e.g. white and off-white background, unlike for tables. More likely an alternation between 3 or 4 subtly-different colors is best; maybe these can form a pattern across additional lines (e.g. 121312321). If the difference isn't subtle enough, editing will suffer whenever you break the line count, but for reference only the human eye is pretty good at aligning subtle things. Maybe even an outright paper-texture background image? (This is more often a gimmick, but it can be useful.)
      • ycombobreaker 2y ago
        Why exclude indentation? A block of code that is indented say... 5 levels deep at 4 spaces is missing 20 columns. If that loss of space gives the developer discomfort, it sounds like a healthy reminder about complexity. Every level of nested scope is additional mental context of "global" state for a maintainer. There should be (reasonable) pressure on the author to refactor towards less indentation/nested scope.
        • andyferris 2y ago
          It's an interesting point. You can't have it both ways though - support hard line limits because the mere discomfort of long lines is insufficent to convince the programmer to refactor to something clearer, and then argue that the mere discomfort of the line limit including indentation should convince the programmer to refactor deeply nested code into something simpler. Which is it? Do we want to force limits with say a linter (80 characters of width max, 5 levels of nesting max) or let the programmer choose based on comfort? I've had to implement things like an arbitrary-JSON formatter. Setting a fixed width including indentation doesn't work - there would always be (deeply nested) values you simply cannot print according to the rules (excluding, of course, strings which have their own difficulty). I kinda feel 80 characters excluding indentation works out ok in practice in a variety of settings.
  • taeric 2y ago
    Took me a second to realize ETA was "edited to add." I was very confused on what an estimated time of arrival meant, here. :) I'm surprised reading on a phone is common. Not at all something I would want to do. I'm assuming largely read only there? Makes me curious if the CWEB idea of styling specifically for reading has extra merit in that flow?
    • NikolaNovak 2y ago
      I've been reading books on phone since palm pilot and 160x160 screen. I do not want to type / create on my phone though, certainly not code, or even sign up for stuff / submit / do applications on phone. Makes me a rarity though.
    • aithrowawaycomm 2y ago
      I don’t know how “common” it is, but (like I said in my comment) the only reason I read code on my phone is that I am often on a bus or a subway. The comment about assuming I only read on my phone is bizarre: you are putting words in my mouth for reasons I do not understand. When it comes to books I like paper, and I usually read long PDFs on a tablet.
      • deleted 2y ago
        [deleted]
      • necovek 2y ago
        GP was not assuming you read only on the phone screen, but that you use phone just (only) for reading ("read-only") and not for editing.
      • taeric 2y ago
        Sibling post is correct. I meant that as a question on if you edit while on the phone.
        • rphv 2y ago
          “read-only” might have removed the ambiguity there
  • thayne 2y ago
    On the other hand, horizontal scrolling on a touchscreen is more natural than with a mouse.
    • eviks 2y ago
      It's not, with a mouse I can scroll vertically with a Shift to scroll horizontally On a phone touch screen horizontal scrolling is also less ergonomic than vertical due to less range (and less ergonomic than vertical mouse), but I can't replace it
• comradesmith 2y ago
  I think 110 is a nice spot. You can still split screen but also fit a lot of content on one line
  • keyle 2y ago
    Honestly it depends of the language you're writing in too. Some language are just long and wordy and having a 'fixed' size just leads to awkward line splits. e.g. all the languages that tend to favour 2 space tabs.
• drivingmenuts 2y ago
  I use 120 or 132 (no idea why I picked that number), but I tend to break my lines well before that, especially on function signatures. I'm that git that puts each param on a separate line (so I can quickly comment them out when I need to). It annoys other programmers, but once I explain why ... They're still annoyed, but at least they're quiet about it.
  • qayxc 2y ago
    > I'm that git that puts each param on a separate line I do that too :)
  • bitwize 2y ago
    If you're that git that makes one param per line a standard that you can flunk code review for not adhering to, I'd seriously consider switching jobs were I under you.
  • SoftTalker 2y ago
    Some old "dumb" terminals could be switched into 132-column mode, this corresponded to the 132 columns on the line printers that printed on wide fan-fold green-bar paper. The 80 column standard for a line of code goes back to the 80 columns on a standard IBM punch card. Why 80 columns on a punch card? I don't know that one.
  • beeflet 2y ago
    I will do this, but only if it has many parameters. It makes it easier to visually parse the function name, templates, outputs, etc. from the parameters than if they were all on one line
• koito17 2y ago
  The penultimate paragraph of the article really shows its age. When there are unclear or conflicting rules ... [y]ou can end up with hilarious games like formatting tennis ... Back then, formatters were rarely used, if at all. The major benefit of tools like gofmt, Prettier, etc. is that a major source of vacuous commits and code review has gone away. In the case of Prettier, bikeshedding can still happen over the .prettierrc file, but it's not hard to make an argument for using the default configuration. Formatters are something I miss whenever using languages without a widely-used formatting tool. For instance, in Common Lisp, code formatting is "whatever Emacs does when formatting the whole buffer". Depending on the exact package used (e.g. SLIME or SLY), the results of formatting the whole buffer may differ. Contrast this to languages like Go where there is one tool (gofmt) and it exposes no configuration, so there is no possibility of bikeshedding over code formatting.
  • j1elo 2y ago
    In new projects I usually add an empty .prettierrc file with a single comment: // Empty file. Use default Prettier settings. No rules here. To make it clear for other people that it was not just a mistake that the formatter was missing its configuration or that no config file existed at all. Useful to deter from adding new rules because someone is capricious about their own preferences...
    • vhcr 2y ago
      Maybe even add a CI step that closes PRs if someone modifies formatter config files.
      • xandrius 2y ago
        And fires them too, while we are at it!
    • koolba 2y ago
      I like to put a haikus in spots like this: // Empty by choice // Use the Prettier defaults // No customized rules Taking the time to write a specific one gives added weight to the decision to use the defaults as anyone adding a rule has to remove the haiku.
• rusk 2y ago
  65-80 for readability however once you introduce indentation this naturally increases. I always felt that shorter lines were a good way to encourage less nested code. Alas after all these years the consensus is against me.
  • anonymous_union 2y ago
    i'm with you
  • accrual 2y ago
    I still like 80 columns even on modern hardware and displays. It encourages me to keep my lines tidy and to break long lines apart. Sometimes I go a little over, but it's a nice target to reach for.
  • DeliriousDog 2y ago
    Completely agree on limiting yourself reducing the nesting of code. There is more difficulty working with code such as if x { //... } else { //... } Than code like if x { // returns from this block } // execution continues In some legacy code I sometimes encounter very long chains of checks which nest 4-8 layers, which becomes very difficult to maintain a mental model of where you are in execution at any point. I try to refactor into the second pattern from above when possible.
  • tariksbl 2y ago
    agree. i think google python formatter kept lines at 65, i was surprised but it made you keep things concise & ended up much more skimmable.
• layo 2y ago
  100 chars is the sweet spot for me. It allows you to have 2 files opened side-by-side in 1080p screen resolutions and even better for 2k res. 24"/27" monitors are the new standards. I think 100 characters is called to replace the traditional 80 characters rule.
• satiric 2y ago
  At home, if I put VS code on my 1080p 24" vertical monitor, I can see about 100 columns (at a reasonable font size, with the VS code sidebar up). I find that to be a little limiting at times but not too bad, and I can close the sidebar to get to 120 columns. Minor issues with horizontal character count are definitely worth it for the massive vertical space though (about 100 lines of code). I've been thinking about replacing it with a 27" 1440p monitor to get a few extra inches of monitor width at about the same pixel density.
• Minor49er 2y ago
  Sticking with 80 characters has been great for my team. Not only does it encourage shorter lines, but comparing diffs on GitHub ensures that both old and new comparisons fit evenly on the page without any cutoffs or wrapping
  • shiroiushi 2y ago
    What kind of monitors does your team use? I view diffs side-by-side all the time with much wider lines than 80 chars, but I have 27" monitors, which are not unusual these days.
    • throwaway2037 2y ago
      In my experience, people who use wide monitors are more OK to longer lines. The opposite is true for tall/vertical monitor users. The next question: What is the chicken and what is the egg? Do people prefer narrower lines because they prefer tall monitors? Or vice versa?
    • Minor49er 2y ago
      All of my main external displays are 27". The diffs fit perfectly on them with the 80 character limit
      • shiroiushi 2y ago
        You must have your text size set to 18pt or something, because I can easily fit 3-4 columns of 80-char text on my 27" monitors.
        • Minor49er 2y ago
          It's whatever the default scaling is on GitHub. I could fit more in other contexts of course, but on the site, that's the perfect size with a 27" monitor
• akira2501 2y ago
  > This is because, back in the bad old days, most computer terminals could only display 25 rows of 80 columns of text on screen at once. And this is because, back in the super old days, most computers used punched cards. Which had 80 columns.
  • thangalin 2y ago
    > back in the super old days, most computers used punched cards. Back in the super-super-super old days, looms were "programmed" using paper tape, which eventually influenced the 24-column Hollerith cards for the 1930 census, and ultimately resulted in a horrific application of technology. https://dave.autonoma.ca/blog/2019/06/06/web-of-knowledge/ https://dave.autonoma.ca/blog/2019/06/06/web-of-knowledge/
• delichon 2y ago
  I maintain 80 characters in order to edit files side by side on a laptop screen without side scrolling. I seem to grok code better vertically too.
  • bearjaws 2y ago
    I love how everytime this debate comes up, the 80 character gang keeps adding more stuff to put side by side. Now we're shrinking the resolution/sizes of the devices we are using to justify it...
    • loloquwowndueo 2y ago
      Gotta admit a three-way side by side diff/merge is glorious.
      • throwaway2037 2y ago
        Have you ever tried it on three monitors at the same time? For me, it is a real game changer when trying to deal with a difficult, conflicting merge.
  • eviks 2y ago
    If you soft wrap you can avoid scrolling inn this case for any line length without negatively impacting the case of a single file
    • funcDropShadow 2y ago
      Is there any editor with an intelligent soft-wrap? I.e. it doesn't just wrap at the end the window. Line breaks should be introduced so that the tree structure of the code (think AST) becomes obvious. That improves readability a lot compared to breaking lines at a fixed column.
• type_enthusiast 2y ago
  I think the answer is pretty clearly "no, but" (or "yes, if"). Of course it depends on what you're doing – if you're writing shell scripts, it might make sense to keep them at 80 characters in case you have to go down to the data center and edit them from a terminal because your network card failed. But for most code, there's no particular limit that makes sense (in my opinion). I'm somewhat against code formatting "rules" in general. If it's about readability (/aesthetics), different code will have different properties that make it readable or unreadable. Sometimes, forcing a line break makes code less readable. In other situations, it can have the opposite effect. IMHO, it's a local decision – and the human that's working on that code is better at deciding what's readable than a linter is.
  • necovek 2y ago
    I agree with you that writing readable and aesthetically pleasing code is more art than science (that can be expressed with deterministic rules), I still find some of the rules and rule-checkers beneficial (though I dislike strict formatters). As such, 80 is as good a limit as any, and makes you think carefully about avoiding deep nesting of blocks, which is usually a good idea anyway. It also allows putting many windows side-by-side on a modern big 4k screen.
    • type_enthusiast 2y ago
      I have to push back here a little bit. It really depends. I mainly use Scala, and I think the majority of Scala code would be far less readable if forced to 80 columns, than if it were a larger number (or simply unconstrained). My WFH monitor is an Apple Thunderbolt Display, which is woefully out-of-date now. Even on this display, and even though I use a much larger font than most people (16pt Hasklig), and even with a generous project/navigation/etc sidebar, I still get 180 characters. The display I have in the office is even wider, but I can't measure it right now because I'm not there. My point is, displays are now wide enough where arbitrary line limits don't make sense. Nobody is going to cram stuff into one line unnecessarily, so just leave it up to the local decision about what makes the code most readable. If for some reason a 240-character line is more readable in some situation, then we should talk about that situation rather than why they didn't break the lines.
• shmerl 2y ago
  Short answer - it is not.
• PeterWhittaker 2y ago
  > formatting tennis That's a paddling. Seriously, professionals do this? If someone else wrote it and it does what it is supposed to do, it is not, NOT (no apologies for shouty emphasis), my job to change that. (I hate tabs, but will never :retab someone else's code.) My job is either/both to fix bugs and add new capabilities, not to be precious about, well, anything. I would have serious reservations about any team member who wasted all our time on that.
  • mattnewton 2y ago
    I agree this is terrible primarily because it muddles up any git-blame based workflow for debugging regressions. I think an autoformatter with the config checked into git is a nice way around this.
    • zamadatix 2y ago
      This approach comes with the benefit of automatically fixing those who simply don't realize their editor's settings disagreed with/didn't pick up on the conventions the project follows.
    • Wowfunhappy 2y ago
      > I agree this is terrible primarily because it muddles up any git-blame based workflow for debugging regressions. ...it occurs to me, this feels like you're conforming to the tool instead of the other way around. Is there a reason git blame doesn't have an "ignore whitespace" option? Is it harder than it seems?
      • nemomarx 2y ago
        I would think the issue is that if you format someone else's code, gitblame then sees you editing that code? Unless you can mark that commit as white space changes only somehow
        • senderista 2y ago
          You can tell `git blame` to ignore entire commits: https://gist.github.com/kateinoigakukun/b0bc920e587851bfffa98b9e279175f2 https://gist.github.com/kateinoigakukun/b0bc920e587851bfffa9...
• sethammons 2y ago
  Does it help readability? Sometimes a long line is crappy, and sometimes breaking it up is terrible. I HATE how my python looks after pep-8 gets ahold of it. Before Go, I was team 120-ish instead of 80 as it tends to not break as many otherwise legible lines. After Go, I removed my 120 char ruler in my editor.
• tom_ 2y ago
  I have a line length limit I personally stick with, because it works for the display setup I have. But - I don't actually care all that much! I have truncate-lines off, word wrap mode on - or whatever the text editor calls it - so I never miss anything. You could do this too, and now the question of the character line limit becomes much less relevant.
• driggs 2y ago
  For Python source code, where indentation is significant, I'm convinced that long lines should never be broken early. It should be the IDE's job to (optionally) fold long lines dynamically to the width of a viewer's editor. If someone breaks a statement early at 72, or 79, or 99 characters (PEP8 recommendations), indentation no longer represents the structure of the program, it now represents the style of the author. Everyone who uses a wider screen suffers. But if the IDE knows how to fold long lines dynamically, then any reader can use any width screen for viewing and editing. And users may choose not to enable folding at all, so that indentation exclusively represents program structure.
• golergka 2y ago
  Yes. Vertical splits.
• bigstrat2003 2y ago
  80 characters is way, way too short. I think 120 is a decent spot for today's displays, although I don't mind even longer than that either.
  • eikenberry 2y ago
    IMO 120 is the extreme limit but a good limit. Anything higher than 120 is to long and, personally, I'd ask for that to be fixed in a code review.
    • malfist 2y ago
      120 is way too small. IMO 180 is a good limit. We're not on 800x600 screens anymore
      • shric 2y ago
        I have three 4K monitors and use a small font and think 180 is way too large. Long lines are less readable and I want to have several terminal panes or editor windows side by side.
      • Gigachad 2y ago
        Lots of people are using split screen editors though. Tbh if you are butting up against the 120 limit, you're probably doing something wrong and could easily break the lines, or use less levels of indentation.
      • eikenberry 2y ago
        Over 120 and most likely something is wrong with the code. That many levels of indentation usually means that code's cyclomatic complexity is off the charts and is in desperate need of refactoring. It could indicate bad naming practices (to long) which also should trigger refactoring. This is all to say it is more about what long lines say about the code than anything to do with the display. Some languages are just naturally worse at this (eg. Java), so there is always some flexibility. But for most languages that don't have multiple levels of indentation by default and the custom of overly long names, 120 is more than enough to be a good guidepost.
• bigfatkitten 2y ago
  I like 80 columns because I like to use multiple applications at once. 80 columns is about the sweet spot to have an editor on one vertical half of my laptop screen with the font set to a comfortable (read: large-ish) size, with something else (e.g. a browser) on the other side.
• lijok 2y ago
  How unfortunate that line lengths ended up being a source code concern instead of a text editor concern.
  • beeflet 2y ago
    well I think the problem is that people use indentation to visually see the context of a block of code, so when you wrap text it messes that all up and if you have code with long variable names and a lot of indentation, there isn't much you can do to prevent the column from going over a certain amount of chars. People (including torvalds) complain that some small limit like 80-chars does not make good use of screen width. Maybe the solution in whitespace-independent code like C is just to "reset" the indentation after a certain amount, or just choose not to indent certain blocks? I just use tabs and set my tab length to 2 or 3 chars. IDK how text editors would adjust the source code to fit multiple screen widths. When I have a line that's too long for the line limit, I have to re-arrange the code in that line to get it under the limit.
• lcnPylGDnU4H9OF 2y ago
  Considering how easily I lose track of my position when reading long lines and how easy it is to read vertically when lines each have a single word on them, I seriously question the method by which most developers determine that they prefer >80 character line length limits.
  • fragmede 2y ago
    How descriptive are your variable names and how how many of them are you passing around? Comparing x to y in a few different ways will easily fit into 80 columns, but you can only put something like machinePoolControllerGroup or webhookControllerRuntime a couple of times before hitting 80 chars with indentation.
    • lcnPylGDnU4H9OF 2y ago
      I use descriptive variable names and I do sometimes run into issues around that. Sometimes that means putting the variable which is on the right of the comparison on a separate line, indented, but I’ll admit that carries its own ugliness. It’s not perfect but I do have difficulty reading those really long variable names on one line so I’m not shy about splitting things on multiple lines. I assume others don’t lose their place as easily but I doubt I’m alone in that at the same time.
• dqh 2y ago
  An 80 character limit is difficult to stay within when using highly descriptive variable names, and I think the benefits of highly descriptive variable names outweigh other considerations.
  • echelon 2y ago
    It's not impossible if you're using an indent of two spaces and not doing a lot of nesting. I think 100 characters would be a better limit, though.
    • dqh 2y ago
      Yes, not impossible, but in my opinion requiring a waste of energy.
  • bcrl 2y ago
    In my experience, if your variable names are long enough to overflow an 80 column limit, you've probably already got a problem. Longer variable names have a cognitive load in and of themselves, which, to me, usually means someone didn't think about naming enough or is subject to too many levels of pointless indirection. To me it is important to try to keep code concise so that it is easier to read. This applies to variable names as much as it does to how many lines a function is. The smaller the unit of functionality it is, the easier it is to understand in its entirety.
    • flakes 2y ago
      I care less about the length of the code, and more-so about the cognitive load. As the business logic grows, and the lines of code increases, the assignment of variables tend to get further and further away from their usage. What was once simple to read, now requires back-tracking as you read to double check exactly what they are. Consider this contrived example: margin = (price - cost) / price You can be reasonably sure what is being calculated, but it's hard to be exactly sure unless the surrounding context is very small. Having longer names allows you to keep more context for a line in isolation, meaning (personally) I require less backtracking while reading. e.g. the above could be rewritten as the following, removing a lot of ambiguity: retail_margin = (retail_price - wholesale_cost) / retail_price I find 80 character limits much too small in these cases. 100-120 characters is the sweet spot for me. I can still have 2 split panes of code on a single screen at once, and write more expressively without excessive linebreaks per statement.
• kibwen 2y ago
  Note that when we talk about line length limits, we're actually conflating two separate concepts: 1) The maximum width of our viewports 2) How long we want our lines to be WRT the second concept, the general rule of typography is that a line should be 60-80 characters long. But, crucially, this is not counting indentation; a "line" here begins at the start of the text, not at the start of the margin. In the modern day we could decouple these two concepts. Imagine a standard code format that assumed a maximum viewport of, say, 120 characters, but still wrapped lines when they reached 80 characters in length, not counting indentation. Then you could get the benefits of both enforcing a maximum viewport size while having a comfortable line length for reading.
  • eviks 2y ago
    Is there a single formatter capable enough for this?
    • kibwen 2y ago
      Any formatter that already wraps on line length is capable enough for this, it's just a matter of taking the existing line length check and adding a single new conditional.
• xadren 2y ago
  I largely prefer an 80 column limit. On my external monitors with no file tree open, I perhaps could utilise more columns comfortably, but that really falls apart if I need to work on my laptop's screen. The side effect of this that I don't particularly love is having to split a function's arguments on to multiple lines. Usually if I'm at that point though, I'll probably end up having to split those arguments up event at a ~100 character column limit. To me, splitting the arguments is the preferable of the two situations. I always want to be able to see the whole line.
• clcaev 2y ago
  For accessibility, I prefer 80 characters. With a large screen, at a font I can read, there are about 83 characters before the line wrap. There are formatters though. The issue then becomes the git diff. This seems awfully like the tabs vs spaces debate.
• lcuff 2y ago
  >at a comfortable 10 point font size. How lovely for you. As someone with significantly impaired vision, even when corrected, I have my font size set to 18, thank you very much. A coding standard that assumes a 10 point font size would violate the Americans with Disabilities Act's 'reasonable accommodation' mandate. I wasn't pushy enough to act on it, but it sure pissed me off when my fellow team members blew off my complaints about how we formatted our code. (Including two space indents...grrrr.) My worse than 20/200 vision (Can't see the big E on an eye chart) lets me see code, but legally, I'm blind in one eye. I admit, it's a classic 'no perfect solution' scenario, because I like very long variable and function names. I write tiny functions (5-10 lines) because they only need one or two levels of indent. Some programmers I've worked with really dislike such small functions.
  • CrimsonRain 2y ago
    Write tiny functions because of aesthetics; not because the flow calls for it ಠ_ಠ
  • nwiswell 2y ago
    > A coding standard that assumes a 10 point font size would violate the Americans with Disabilities Act's 'reasonable accommodation' mandate. Would it? You can still set the size to 18, you just might have to scroll or line wrap. That's a mild inconvenience, not "inaccessible".
  • lmm 2y ago
    > A coding standard that assumes a 10 point font size would violate the Americans with Disabilities Act's 'reasonable accommodation' mandate. Would it? I don't think having to make all my lines 44% shorter than they should be is reasonable; that's going to be a massive impingement on productivity.
    • lcuff 2y ago
      44% shorter: is your claim that limiting line lengths to 80 or 100 characters is going to 'massively impinge' your productivity? That seems unlikely to me.
• crackez 2y ago
  Sure, for JCL and COBOL...
• zzo38computer 2y ago
  Some other considerations: 1. Use of DOS programs. 2. Printing out on a paper. 3. Split screen. 4. Other people who view, with different screen resolutions, and preferences for font sizes, window sizes, etc. These are also some reasons why you might still prefer to use a short line limit, too.
• sghiassy 2y ago
  Am I the only developer who preferS long lines?
• coretx 2y ago
  It's as relevant as the 4:3 aspect ratio still being the best as it correlates to the physical properties of our eyes. That said and knowing that nearly every modern day OS is capable of resolution independent functioning; we should start rendering interfaces based on the distance from the eyes to the screen and it's size. Someone probably already did the math on this.
• danesonance 2y ago
  One disadvantage about long lines is during debugging: 1) as you step through your code having one megaline is difficult and 2) when you're looking at a bug in your terminal it can be harder to tell where the issue is.
• debuggerpk 2y ago
  it was not relevant in 2022. In 2024, with AI agents, it is relevant again.
• dcow 2y ago
  I don’t care how ultra your wide is, reading anything horizontally is painful and unwieldy. It’s biological, your eyes can’t track horizontally without row guidance, and even then it’s not hard to get lost. I have one rule: code flows vertically. I like reading books. Code should read as easily as a book. I have found that if you constrain your code to being shaped like a book, almost everything else follows naturally. You can’t be indented 7 levels into hell if your code has a reasonable line limit. You can’t jam arbitrary numbers of statements onto a single line. You have to decompose your control flow at reasonable function breaks. Lines are a better primitive for editing and debugging. Etc. etc. etc.
• charles_f 2y ago
  One thing I find sad is that of the 4 IDEs that I work with, most of which have an option to break done long line into several multiple line equivalents, none allow to do a word wrap smarter than that of notepad. They already implemented the refactoring tool, using it in rendering would probably not be a far fetch. That would allow us to get past handling line breaks manually and the invariant discussions and review comments on how best to line up function parameters and comments in 2024.
  • throwaway2037 2y ago
    That is a lot of IDEs! Why not use IntelliJ for everything... Or Eclipse or Visual Studio Code? I am pretty sure all three are uber polyglot at this point.
    • charles_f 2y ago
      I use rider where I can, xcode for ios because you don't have a choice, VS for a few things where, similarly, I don't have a choice, and vs code for one of the projects because my company built a bunch of extensions to deal with the codebase
• bbor 2y ago
  SavedYouAClick: no
• block_dagger 2y ago
  A couple years ago I had a pinched nerve in my cervical spine that prevented me from doing desk work so I built a supine workstation that used an ipad as the screen. I found that the 80 character limit was very helpful in that situation and I wonder how many other disabled devs might agree, especially those with vision issues.
  • fastball 2y ago
    Why'd you use an iPad as a screen instead of a more traditional screen?
• alganet 2y ago
  I like the 80 limit. Makes me think harder about what I'm doing. Some languages are naturally wider (Java, PHP, etc). I those, 120 is fine too. Also, I tolerate comments past the 80th column but not code.
• __mharrison__ 2y ago
  Most of my code is pandas these days so chaining with a 40 char limit is usually fine ... Ducks.
• binary132 2y ago
  Just because some people like to have a single pane of text cover their entire 16:9 display doesn’t mean I should have to. I find very vertical text much easier to follow. Wide lines are usually wide due to nesting and chaining, either of blocks or of inline expressions. Both are a thing which should not be. Concisely and clearly define one concept or abstraction. Then, use it in the next definition. This isn’t hard! And stop with the insanity-inducing compound names. If your name needs 5 subclauses to clarify its intent, your semantics are stupid and you should be beaten with a shoe.
  • duxup 2y ago
    > doesn’t mean I should have to. I don’t believe the article says you should have to.
    • binary132 2y ago
      What I mean is that if I’m working on a file with some other people, and I write some 80-column code, they can easily view it in their nice wide panes, but I can’t easily view their wide code in my nice tiled square or vertical panes. I often have as many as 8 (or more!) tiles in a single fullscreen window.
  • jltsiren 2y ago
    And some people like me prefer using large fonts, because my vision is not very good. The code pane in the full-screen VSCode window I have open on a 27" display is 145x37. Full-screen mode would add one more line. And those 145-character lines are typically enough for ~110 characters of code, because the editor adds various annotations. That gives me an effective working space of 110x37. Any concept that needs longer lines or more lines is going to be harder to follow.
  • sfpotter 2y ago
    It's hard if you don't know how to do it... and lots of people don't know how to do it.
    • 2y ago
• RHSeeger 2y ago
  In my mind, it's a balance between expressing the flow of control/algorithm vs the details. You can have 20 long lines (admittedly, some blank because it helps readability) that show what is happening... or you can have 200 lines (because you broke out each argument to a function on it's own line, etc), making it much harder to look at the code and see what happening "overall". Sometimes the details are more important, sometimes the flow of control/algorithm is.
• russellbeattie 2y ago
  Fun fact: 80 characters comes from punch cards, specifically the IBM card format, introduced in 1928. It improved on competing card formats by having rectangular holes which allowing tighter packing of holes. The result was 80 columns and 10 rows per card. Each column on a card indicates a single character or number, so a whole punch card is the equivalent to a single line of text (and was usually treated as such for programming). Originally, there were only one or two holes punched in each column, providing just enough data for uppercase letters and numbers. But this slowly increased over the years, allowing more characters to be encoded. IBM introduced the EBCDIC standard in 1964, which enabled up to 6 different punched holes per column, encoded in eight bits. This corresponded with the development of the System/360. When terminals were first introduced, they were designed to be compatible with 80 characters per line, as you would expect. Starting with 40 characters per line in the early 60s, eventually terminals like the IBM 3270 had 80 columns as the norm. This was then copied by microcomputers. The Commodore PET launched with 80 x 25 character support right away. The Apple II originally had 40 characters per line, but they also sold an "Extended 80-Column Text Card" extension board to allow 80 characters (as requested by VisiCalc). This was built in to the business focused Apple III, and later into the IIe. The "e" in IIe stands for "extended". The original IBM PC's Monochrome Display Adapter had a 720 x 350 display, with each character contained in a 9 x 14 box. 720/9 = 80. As higher resolutions became the norm, editors began to put a line on the screen to visually indicate 80 characters. Certain programming languages have an 80 character per line limit like COBOL or FORTRAN, so the line did serve a purpose at first. But later it became sort of vestigial. And here we are now, a century later, debating whether 80 characters is still a good line limit for code.
• eviks 2y ago
  And not a single mention of soft wrapping > Long lines that span too far across the monitor are hard to read. This is typography 101. The shorter your line lengths, the less your eye has to travel to see it. But the longer your eyes have to travel vertically, so 101 doesn't justify a specific number 80, thus doesn't help much in resolving the trade-off
  • fsckboy 2y ago
    i don't think that guideline is correct, it's "the shorter your line lengths, the less your eye has to travel to get back to the left margin, the quicker and more error free you'll find the next line" and no similar idea occurs vertically, save that it is already mediated by vertical section markers. (I very frequently wish that hitting page down would show me a distict mark where the previous bottom of screen is now)
    • eviks 2y ago
      Maybe, though I've also read fundmentals care about eye strain, where distance could matter? > hitting page down would show me a distict mark where the previous bottom of screen is now) For a literal page down the last line would literally become the first line, but yeah, that's the mark/animation that could be useful for when it's not a page
      • fsckboy 2y ago
        no, for a literal page down, the first line on the next screen would become the new first line, with zero of the previous page still visible (which would be perfectly fine with me, I simply would like either that everything work the same way, or I get a visual indication of what just happened so I don't need to hunt for where to continue reading
• magios 2y ago
  on a 1920x1080 display using bitmap fonts or their equivalent where each cell is 8x16, then three tiled windows without borders are 80 characters wide. font used is unifont, i3 window manger, xst terminal, vim, etc. if i had a 2560x1440 display, i'd use four 80 character wide tiled windows.
• qwerty456127 2y ago
  It still is relevant in 2024. > An 80 character limit has no relevance any more with modern computer displays. It's still nice to keep the code or anything readable on a vertical mobile screen.