1. 24
  1. 39

    I worked with a legally blind programmer who had enough vision to set up a giant monitor with huge text put his face up to the screen to read it. When people started going on about line lengths the argument ended because he could fit 80 characters that he could see on a big, ultrawide monitor without having to scroll horizontally (which was a nightmare for him because he couldn’t see the horizontal scrollbar at the same time as he could see text).

    He was a great engineer and coworker. Everyone agreed that they wanted him around more than they wanted long lines.

    1. 3

      Why was line-wrapping not an option?

      1. 6

        Do you consider line wrapping an option for your own work? I don’t.

        1. 1

          Because line-wrapping is incredibly annoying when coding. I wouldn’t like it. Why would I force it on him?

      2. 6

        Copied from my post on the orange site.

        I’m glad that the terminal 80-character limit was mentioned and that humans struggle with longer lines. In fact, the optimal line length is 50-75 characters 1, which is just right for 80 characters with 1+ levels of indentation.

        That last one is the reason why I still keep a hard 80-character limit on my own code, even though I have a 4K monitor, and a big one too (43 inches).

        But doing so actually has a great side effoct: keeping an 80-character limit with a 4K monitor means I can have four files open side-by-side. 2 Or a file open in four different places. Or a file and its associated header both open to two different places.

        It also means that I can see the code completely while debugging with four columns. 3

        1. 1

          Hard-wrapping at 80 characters means that those who prefer less than 80 characters are stuck with the formatting that you imposed upon them, and those that prefer more than 80 characters are also stuck with the formatting that you imposed upon them.

          Furthermore, if I need a larger font size than you do, then suddenly I can’t fit four of your 80-character hard-wrapped files onto my screen anymore, because if I turn off soft-wrap then I have to scroll, and if I turn on soft-wrap the results are unreadable for blocks of consecutive hard-wrapped lines.

          Respect people’s editor preferences. Don’t hard-wrap your code. Soft-wrap has existed for decades.

          1. 5

            Soft-wrapping completely ignores indentation. That’s not a workable solution either, and it will continue to be until editors can not only soft-wrap, but soft-wrap and place the extra code at the same indentation that the line has.

            It’s this:

                stuff = more_stuff + way_more_stuff - you_know_who_is_going_to_get_you * there_is_a_sad_sort_of_clanging *
            (he_who_must_not_be_named / infinity_and_beyond + wont_you_be_my_neighbor * star_wars_vs_star_trek)
            

            (pretending that the hard wrap I put in was actually a soft-wrap because lobste.rs creates a scroll bar) versus

                stuff = more_stuff + way_more_stuff - you_know_who_is_going_to_get_you *
                        there_is_a_sad_sort_of_clanging * (he_who_must_not_be_named /
                                                           infinity_and_beyond +
                                                           wont_you_be_my_neighbor *
                                                           star_wars_vs_star_trek)
            

            Until that is possible, hard-wrap with a code formatter that can do it for you in the editor with a hotkey is better than soft-wrap. You mention in a comment in this thread that this is possible, and that it doesn’t exist because people haven’t done it. Have you considered that most people don’t care?

            If you want soft-wrapping everywhere, might I suggest writing your own editor, or language, or compiler that does what you want? In other words, show me the code. And the existence of legally blind people who can’t use soft-wrapping means that your claim in the thread that “then everyone benefits from that point onward” is patently false.

            Also, note that I said that I do it for my own code, where other people don’t matter because they are not even allowed to contribute, so I’m not “imposing” it on anyone. If you require me to soft-wrap, you are imposing on me.

            Let me have my opinion in my own code.

            Also, I note above a comment you made asking why a legally blind programmer could not use soft-wrap. Might I just suggest that you are being a little too evangelical about soft-wrapping if you’re:

            1. Complaining that I impose my style on other people in my own code that others are not allowed to contribute to, and
            2. Asking for justification why someone who struggles with sight might not like soft-wrapping?

            But to answer your question about why a legally blind person would not want soft-wrapping, perhaps their effective vision cone is a really small angle such that they cannot see the line number, or its non-existence, at the beginning of a line, and so they use indentation as an easy way to see if a particular line is a continuation of a line above or not. And soft-wrapping would blow that away.

            In short, your complaining about me not respecting other people’s editor preferences in my own project and questioning the requirements of partially disabled people is not a good look. It’s too evangelical, and ironically, it does not respect other people’s preferences.

            Soft-wrapping is not the end-all be-all. Far from it. In fact, from the comments here, I would venture to say that it is not the preference for the majority of people.

            Please accept our preferences and not try to change them.

            In fact, my original comment only expressed how I felt and how I work. I did not say anyone else was wrong in their opinion of wanting longer lines or soft-wrapping; I merely talked about what I prefer and why.

            You did not accept my preferences, as though you believe hard-wrapping is bad for programming in general. Might I respectfully suggest that if it’s what works for the majority of programmers, including legally blind programmers, that you are wrong?

            I wouldn’t say or imply that soft-wrapping is bad for programming in general; why do you imply that hard-wrapping is? It makes no sense, and you sound like an obsessed evangelist to me.

        2. 6

          I’ve written a bit about the history behind 80-column text, which can be traced back to 1725:

          https://dave.autonoma.ca/blog/2019/06/06/web-of-knowledge/

          At some point I may write another post on the topic of 80-column text. In a nutshell, here are some additional considerations, a few have been mentioned by others:

          • Historical. Reading source code by different teams, in different languages, across projects, over many years without having to resize or scroll horizontally is convenient. Consistent column width restrictions may help with the pace of reading code.
          • Reviews. Reviewing source code diffs often involves two panels side-by-side to compare the changes. At 120 columns, this implies a total possible width of 240 columns, which can lead to horizontal scrolling depending on the reviewer’s computer’s screen resolution, font size, or window size. For a three-way merge, it’d mean 360 columns.
          • Media. Source code having shorter widths can be projected, printed, emailed, inserted into web pages, sent as text messages, and relayed in other media without arbitrarily breaking lines. Also, long lines can affect screen sharing because people watching may be using different screen resolutions.
          • Complexity. Line length is primarily a function of nesting depth, indentation, and identifier names. Restraining line lengths inherently limits the other factors, which curtails complexity.
          • Scrolling. Horizontal scrolling is tedious when reading text, which adds delays, interrupts pacing, and thus can negatively impact source code comprehension.
          • Visual acuity. Some developers require larger font sizes due to visual impair­ment, which decreases the amount of horizontal real estate available for reading code.

          While few studies focus on line length with respect to source code comprehension, numerous studies and typographers discuss line length in printed text. Like printed text, line length on digital displays affects reading speed and comprehension. Long lines slow down reading to the start of the next line; whereas, short lines require more vertical scrolling or paging. Research suggests using shorter lines for accuracy.

          There’s a logical fallacy and a bit of privilege behind thinking that larger displays means longer lines can be the norm. Once 86” displays (or projections) proliferate, 720 character-long lines probably qualifies as reductio ad absurdum. Even though wealthy developers in the United States can afford bigger screens, less wealthy developers are left with less screen real estate.

          1. 5

            This discussion was inspired in part by this discussion on lobsters. Thanks to @arp242 and @spc476 in that discussion who helped clarify some of my views.

            Code width standards are part of a class of questions about coding idioms and shared practices that I find particularly interesting but also surprisingly divisive.

            1. 12

              It an interesting history. The anecdote early on about a vim user needing to scroll was surprising to me because vim has supported wrapping long lines for ages. This is more of a problem for GUI IDEs that are built on top of a scrolling text field to start with.

              Line limit arguments generally come from one of two places:

              • Technical limits
              • Perceptual limits

              If you have an 80-column TTY and no ability to wrap lines in your editor, lines longer than 80 columns are painful. Even if your editor wraps, it typically doesn’t wrap with the current indentation and so now you’re in the territory of perceptual limits: you’ve just broken the ability for readers of the code understand the structure by looking at indentation.

              The bigger perceptual limit is that readability drops for very long lines. The rule of thumb that TeX uses is 66 non-whitespace characters per line, which is based on some data and is well within the region that all of the studies I’ve read agree is the range that’s optimal for readability. I tried with Etoile having a style guide that said no more than 66 non-whitespace characters per line. This composes very well with a rule that says tabs for indentation, spaces for alignment, because it means that your maximum line width isn’t a function of your favourite indent width. Unfortunately, no tooling supported it and so it was very hard for people to follow (including me).

              Scrolling isn’t a problem on modern large monitor but losing your place reading a very long line is.

              1. 9

                My only problem with <= 80 wide (truthfully anything under ~99 or so), is that people name things worse ala “employee_number” vs “emp_num”. Which I know from “Fixing Faults in C and Java Source Code: Abbreviated vs. Full-Word Identifier Names” and What We Know We Don’t Know: Introduction to Empirical Software Engineering the science suggests that doesn’t matter, but it does matter to me. Maybe it’s just what I’m used to, but 80 line codebases are so damn dense, and generally not enjoyable to work in for myself.

                This kind of goes back to the clang-format discussion you and I had over the weekend over here.

                1. 11

                  While Vim can definitely do soft wrapping, the resulting code is often a pain to read. This is because the line is just wrapped across a word boundary, but for code that’s not often what you want. Basically you’d want to soft-wrap it according to the language’s formatting guidelines, but I don’t think there’s any editor out there that supports this.

                  What I always liked about 80 characters per line is that it scales up and down display sizes really well: on a 15” laptop screen with a font size of 8 pt, it lets you have two vertical splits next to each other, while still being able to read all the code (horizontally at least). On a 27” display you can have four vertical splits next to each other, and still have enough space for about 70-ish characters per line. Of course you can also have fewer splits, or put Vim next to another program. Ultimately, the point is that it’s a surprisingly effective line limit.

                  The usual argument “bUt EvErYbOdY sHoUld uSe A 4k MoNiToR” is exhausting, as (at least to me) it shows a complete lack of understanding why these limits exist, and a lack of understanding that it’s not just about display sizes but also about how you use them, what devices are used to view the code (good luck viewing your 200 characters per line code on a phone while taking a poop), etc.

                  1. 17

                    The usual argument “bUt EvErYbOdY sHoUld uSe A 4k MoNiToR” is exhausting, as (at least to me) it shows a complete lack of understanding why these limits exist, and a lack of understanding that it’s not just about display sizes but also about how you use them

                    It’s a very stup annoyi exhausting argument because IMHO it also betrays a general lack of understanding about the act of writing software. You write software for the computers your users have, not for the ones you wish they had, or the computers you think they should have. In some cases, if you’re really operating at the edge of current technology, you may be writing software for the computers they’ll have by the time you’re done, but even that’s a preeeetty risky move, which ought to be done based on as little wishful thinking and as much hard data as possible.

                    This unwillingness to deal with user devices is why so many software interfaces today have awful visual accessibility. Poor contrast (“but everybody should be using a monitor with a good contrast ratio”, “you should be working in a well-lit room anyway”), poor space efficiency (“maybe not now, in 2014, but everyone will be using a touch display by 2019”, “but everybody should use a 4k monitor”), illegible text (“but everybody should be using a high DPI monitor”) are brought about not just by poor design in general, but by an unwillingness to either consider anything other than what looks best in presentations or to let people customize interfaces to fit the limits of their devices.

                    The bit about 4K monitors is particularly annoying since it’s not a generic argument, but a very specific one, about a very specific product line. 4K monitors aren’t particularly cheap. Whenever someone says “you should use a 4K monitor if you want to do any serious programming work”, I imagine them wearing a “stop being poor lol” shirt.

                    1. 5

                      The 4k argument is just laughable anyway, most software works terribly with them. I’ve had to set up 2x scaling on mine (Windows and Linux) because just about every major application is terrible in 4k: at best some of the UI elements scale with system DPI, leading to weird graphics misalignment. This includes popular software like Steam and Firefox.

                      1. 2

                        So not all the time I write software that’s only used by a few people and have had developers come on and do a bunch of customization to match monitors when it is literally cheaper to send them new laptops. I don’t know how common this is but when you’re talking about fairly large budgets shipping out and supporting laptops for 2-3 users is actually not that hard and sometimes get lost. I learned this trick trying to support a CEO’s laptop and was finally like uh can we just get you a new one.

                      2. 8

                        On phones, worse than code is writings hard wrapped at 80 characters with the assumption that everyone has at least 80 character displays

                        1. 6

                          And even worse are people who say you should hard-wrap text because it’s more accessible.

                        2. 2

                          Basically you’d want to soft-wrap it according to the language’s formatting guidelines, but I don’t think there’s any editor out there that supports this.

                          Only because people don’t invest the effort to implement it, because they’re attached to the idea of hard-wrapped 80-character lines. The existence of myriad formatters and linters and associated editor/IDE integration mean that all of the hard parts (parsing, analysis, style application) already exist, and the only thing lacking is integration.

                          I don’t think that one can make a rational argument that hard-wrapped 80-character lines are better than a syntactically aware soft-wrapping algorithm, in which case the only thing left to do is take the existing pieces and implement them. Arguments for 80-character hard-wrap feel somewhat akin to arguments for untyped programming languages - the only benefit is the saved one-time effort necessary to implement the upgrade (to syntactical softwrap/a typed language), and then everyone benefits from that point onward.

                        3. 4

                          Thanks for reading!

                          I’m not a vim user, so I’m not totally sure if the problem was horizontal scrolling, soft wrapping being hard to follow, or what. But definitely, we had some lines that were too long, and having a more heterogeneous set of text-editor used on the team highlighted that.

                          Personally, I like the rustftm way, of wrapping at 99. But any enforced standard makes an improvement in a team setting.

                        4. 2

                          I am an 80 column purist thread had a lot of good discussion too.

                        5. 4

                          I wonder how well most braille terminals handle lines greater than 80 columns.

                          1. 4

                            My favorite thing about columns is that Python’s “Black” code formatter, which bills itself as “the uncompromising Python code formatter”, which is very clear that indentation is four spaces and definitely not tabs, and which has almost no options for any formatting preferences, still takes a “–line-length” option … which defaults to 88.

                            1. 3

                              I am perplexed when the argument, attributing it to punch cards, comes up. There is not such a severe technical limit on the width of punch cards. Why were the punch cards 80 characters? They could have made punch cards much wider if they had wanted to, but what really limits punch card widths is the same as what limits screen line widths: what is comfortable for the human eye to read.

                              So 80 columns comes originally from IBM punch-cards. And I’m sure at least one person listening already knew this because the Stack Overflow question dates back to 2014. And as I said, it’s been shared a lot. But it’s crazy to think about to me. If you can imagine computers existing before computer monitors or keyboards existed, like on a factual level, I know that’s true, but it sounds super strange, right?

                              All my computer interactions have been mediated by keyboards and monitors. I mean, sometimes large CRT monitors, but still, it’s just a weird thing to think about. So before they existed, you had to input all your data or code into computers using punch-cards. And IBM punch-cards looked like recipe stock cards but twice as wide, like the size of a page of a paperback book if you turned it sideways. And the way the programming with punch-cards works is that each punch-card equals one line of code in your program. And a standard punch-card is a grid where you have 10 rows down and 80 columns across. And so that’s where the 80 character limit comes from. You would write your program out in long hand, in paper, and then you would punch it into the cards. And so if you went over 80 characters, you were dead. There was no more lines on the punch-cards. This is like a very hard rule.

                              We’ve kind of appeased Chesterton and his fence now. We know where the 80 characters comes from. It clearly comes because you couldn’t fit anymore on a punch-card. What does that mean? So we can remove the fence, I guess. We’re definitely not using punch-cards now. So the purpose of the limit seems to be gone, right?

                              1. 3

                                I’ve got a decent amount of information on this topic in Appendix A of my Notcurses book (starts on book page 125, pdf page 137). The more interesting question is why 24 lines?

                                Why 80x24 (or 80x25, as you’ll also see)? The 80 almost certainly arises from the desire to display an entire punched card (this is a standard—see ANSI X3.21-1967/FIPS PUB 13, “Rectangular Holes in TwelveRow Punched Cards”). The origin of 24 is less clear. 24 is highly composite (it has more divisors than any smaller number), and it is the largest integer divisible by all natural numbers not larger than its square root. There are of course 24 hours in a day. 24 divides the scanline counts of both NTSC and PAL at 480 and 576, respectively. 24 rows of 80 columns at a byte per column utilize 93.75% of a 2KiB memory, leaving exactly 128 bytes left over, and everyone loves a good power of 2.

                                The Aaronites, Levite descendents of Moses’s brother Aaron, the first גדול כהן) High Priest), form the priestly ים ִנֲהֹּכ ;they were divided into 24 courses. The Buddha’s Dharma Chakra (Wheel of Dhamma) in its Ashoka form sends forth 24 spokes. But perhaps I grow esoteric, even speculative…in truth, 80x24 almost certainly owes its questionable existence to IBM’s punched cards, IBM 2260 and 3270 wanting compatibility with IBM printers, the upstart DEC wanting compatibility with IBM software for their VT52 and legendary VT100, and the VT100 subsequently becoming a de facto standard for four decades.

                                1. 2

                                  I used to be an 80-column purist but I don’t care about it so much anymore. At work we mostly limit code to 100 columns and wrap comments at 80 columns. For some languages the formatter enforces the 100-column limit (clang-format) but in others it’s up the programmer (gofmt). I’ve grown to prefer the gofmt style of formatting, in part for reasons described in the recent clang-format discussion. VS Code makes it easy to have vertical rules at 80 and 100 so I can keep an eye on it. But there are always exceptions, e.g. I think it’s silly to hard warp a URL in a comment since then you can’t click it anymore.

                                  I admit I’m not very rational about these things though. The line length for comments (apart from URLs etc.) should be uncontroversial since it’s easy to have your editor reflow text. But I will absolutely waste time rewording a comment or a git commit message to avoid orphans when reflowing. I wish I could stop doing this.

                                  1. 1

                                    It’s a bit debate in my team…

                                    I’ve been in this game since punch cards and yes, my standard wrap is 70 columns.

                                    A colleague challenge me on this, saying longer lines were more readable.

                                    Alas, like so many of these things, I have found very very little research or evidence to support that argument in either direction.

                                    What little I found was around newspaper column formatting and vaguely supported shorter lines.

                                    His eyesight is definitely better than mine… something to do with being in this game since the punch card days maybe?

                                    In the Bad Old days we had 120 column fan fold line printers with eye lines… https://www.inkanddata.com/2021/06/18/friday-flashback-line-printer-madness/

                                    This stuff.. https://www.inkanddata.com/wp-content/uploads/2021/06/Green-Bar-1-2048x1547.jpeg

                                    The eye lines helped you to follow long lines and not accidentally scan something from a different line as you scanned across the page.

                                    Maybe we need subtle “eye lines” on our editors.

                                    Anyhoo… I’m still wrapping at about column 70, but less pedantic about it.

                                    I await compelling evidence in either direction, until then I declare it “personal preference”.

                                    1. -1

                                      If only someone had searched for the answer:

                                      https://en.wikipedia.org/wiki/Characters_per_line

                                      IBM’s most popular and widely-supported punch cards were 80 chars by 24 lines…. early VTs followed suit, which then begat soft terminal apps on newer hardware.

                                      1. 6

                                        Adam: So 80 columns comes originally from IBM punch-cards. And I’m sure at least one person listening already knew this because the Stack Overflow question dates back to 2014. And as I said, it’s been shared a lot. But it’s crazy to think about to me. If you can imagine computers existing before computer monitors or keyboards existed, like on a factual level, I know that’s true, but it sounds super strange, right?