Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming Linux

Linus Torvalds Argues Against 80-Column Line Length Coding Style, As Linux Kernel Deprecates It (phoronix.com) 296

"The Linux kernel has officially deprecated its coding style that the length of lines of code comply with 80 columns as the 'strong preferred limit'," reports Phoronix: The Linux kernel like many long-standing open-source projects has a coding style guideline that lines of code be 80 columns or less, but now that while still recommended is no longer going to be enforced. This stems from Linus Torvalds commenting on Friday that excessive linebreaks are bad and he is against ugly wrapped code that is strictly sticking to 80 characters per line. This is part of the broader trend that most are no longer using 80x25 terminals...

This deprecation involves updating the documentation on the kernel's coding style to be more sensible and updating the checkpatch.pl script that checks patches to no longer have a max line length of 80. Instead, the check patch script is using a maximum line length of 100.

Torvalds noted Friday that spreading code over multiple lines created problems for single-line utilities like grep, while longer lines "are fundamentally useful..." [H]onestly, I don't want to see patches that make the kernel reading experience worse for me and likely for the vast majority of people, based on the argument that some odd people have small terminal windows... If you or Christoph have 80 character lines, you'll get possibly ugly wrapped output. Tough. That's _your_ choice. Your hardware limitations shouldn't be a pain for the rest of us...

So no. I do not care about somebody with a 80x25 terminal window getting line wrapping. For exactly the same reason I find it completely irrelevant if somebody says that their kernel compile takes 10 hours because they are doing kernel development on a Raspberry PI with 4GB of RAM. People with restrictive hardware shouldn't make it more inconvenient for people who have better resources...

If you choose to use a 80-column terminal, you can live with the line wrapping. It's just that simple.

"Yes, staying withing 80 columns is certainly still _preferred_," notes the official commit message for this change. "But it's not the hard limit that the checkpatch warnings imply, and other concerns can most certainly dominate. Increase the default limit to 100 characters. Not because 100 characters is some hard limit either, but that's certainly a 'what are you doing' kind of value and less likely to be about the occasional slightly longer lines.'"
This discussion has been archived. No new comments can be posted.

Linus Torvalds Argues Against 80-Column Line Length Coding Style, As Linux Kernel Deprecates It

Comments Filter:
  • Sense at last (Score:5, Interesting)

    by Cesare Ferrari ( 667973 ) on Sunday May 31, 2020 @04:43PM (#60128976) Homepage

    Artificial limits to the line length is a mistake, it's a totally arbitrary value, and has horrendous knock on effects. People end up choosing bad variable names as otherwise the lines get too long. The intention was to produce readable code that can be viewed and understood, and if that is the intention, then line length should defer to readability, not the other way around.

    • by bunyip ( 17018 ) on Sunday May 31, 2020 @04:46PM (#60128990)

      Yes! Give me a hard limit of 80 character lines and I'll show you a bunch of 3-letter variable names!

      A.

      • Why do you need more than 676 variables in scope at any one time? Regards, D.
      • by DontBeAMoran ( 4843879 ) on Sunday May 31, 2020 @05:26PM (#60129132)

        How about 1-letter variables? [xkcd.com] (SFW).

        • Instead of 1 letter variables, how about store everything on the stack and use color to decide the type [ultratechnology.com] ?

      • by lgw ( 121541 )

        Overly long names are as bad as overly short names though. FortyCharacterColobNames don't really help, as they're just slower to read. Typically, that's a sign of prefixing or suffixing names with a bunch of needless, repetitive crap.

        Long class names aren't so bad, unless you're that guy who names every variable with a short name followed by the full class name. Don't be that guy.

        • Re:Sense at last (Score:4, Informative)

          by angel'o'sphere ( 80593 ) <angelo...schneider@@@oomentor...de> on Monday June 01, 2020 @11:13AM (#60131268) Journal

          FortyCharacterColobNames
          For many people - like me - they are not slower to read, as we read whole words as a symbol more or less instantly.
          Translation fccn into a meaning full thing requires mental effort for me, though, and slows me down.

      • by msauve ( 701917 )
        But why 100? Line printers do 132!
    • Re:Sense at last (Score:5, Interesting)

      by hey! ( 33014 ) on Sunday May 31, 2020 @05:04PM (#60129042) Homepage Journal

      I agree that arbitrary limits are a bad thing, but rules of thumb can be a good thing, as long as you know the correct thing to do about them. It's kind of like a grammar checker; you can't really rely on its advice because it doesn't know what you're trying to say, but when it puts a lot of flags on a sentence, that sentence nearly always needs some attention.

      I started programming on VT220s, which were 80 columns x 24 lines. This is a rather small window into code; when functions are over a hundred lines long, or indents to more than fifty columns, it hampers your ability to understand what's going on. But the right answer wasn't to *mangle the formatting* of your code to make it fit. The answer is to refactor your code so that when you're looking at a function or procedure, everything you need to see to understand it is nearby.

      Even then you have to apply common sense. The goal is to make the code readable, assuming it works well enough.

      • The answer is to refactor your code so that when you're looking at a function or procedure, everything you need to see to understand it is nearby.

        This. I noticed that when I set myself to adhere hardly to an 80 character limit, that what I wrote started to become more refined and coherent. I never write multiple line prototypes or broken lines anymore, but I will give myself some leeway if it goes over a few characters.

      • Re: Sense at last (Score:5, Interesting)

        by ttfkam ( 37064 ) on Sunday May 31, 2020 @05:25PM (#60129128) Homepage Journal

        I *continued* on vt220 terminals (and vt100 terminals before them). That size came from teletypes. That size came from IBM punch cards. That size came from matching the size/format of 1890 census cards. That size came from US currency during the 1880s.

        Similarly to the cargo cult history of the standard gauge railroad rail width coming from old Roman roads, which were optimized to accommodate vehicles like chariots of the time, whose wheel separation width was defined by the standard width of two horses side by side.

        Learn your history.

      • > when functions are over a hundred lines long, or indents to more than fifty columns

        Right about there I thought you were going to say you need longer lines, so that each function could have 70 lines of 120 characters each. Gotta have that column width so you can indent 20 levels, right?

        > The answer is to refactor your code so that when you're looking at a function or procedure, everything you need to see to understand it is nearby

        So much this. One thing I learned late in my programming career, somet

      • I think you will find that VT220 had a 132 column mode.....

      • It should be a rule of thumb that code as written should be understandable by a new hire or a novice. It should not be written so that only others highly experienced in the project understand it. Someday, maybe a long time off, someone else will have to maintain the code and the original author will be long gone. Prepare for that day from the start!

    • Re:Sense at last (Score:5, Informative)

      by techno-vampire ( 666512 ) on Sunday May 31, 2020 @05:09PM (#60129058) Homepage
      Artificial limits to the line length is a mistake, it's a totally arbitrary value,

      No, it's not an arbitrary value, there was a good reason to pick it at the time. Specifically, it came from the early days of computing when most if not all input and output was via punched cards. Punched cards have eighty columns, making for eighty card records and eighty column lines. That doesn't mean that we have to be tied to that standard now, but it does demonstrate that the number eighty was never arbitrary.
      • Isn't it also the width of a VT100 terminal?

        • No, that was the VT52; the VT100 also had a 132 column mode. The 80 column standard went back at least to the '60s, when I was using punched cards to program an IBM 1620.
        • And if VT100 terminals had an 80-columns limit, why weren't they called VT80?

        • Yes. They choose that width because it was the width of the punch cards the terminal was replacing. The alternate width of 132 characters was because that was the standard width in large-format printers.

      • but it does demonstrate that the number eighty was never arbitrary

        Except for the original number eighty, you mean?

        • Don't put words in my mouth, it violates social distancing. The 80 column limit was imposed by the size of the Hollerith Cards that were used for input.
      • by lgw ( 121541 )

        No, it's not an arbitrary value, there was a good reason to pick it at the time. Specifically, it came from the early days of computing when most if not all input and output was via punched cards. Punched cards have eighty columns, making for eighty card records and eighty column lines.

        Punched card did not have 80 usable columns, though. Usually the last 6-8 columns were reserved, and ignored on input. They were used for sequence numbers, continue character, and the like.

        The "80 column mind" comes from early displays. Sure, the displays were 80 columns because the cards were, it's not arbitrary, but you didn't code 80 columns wide in the early days.

        I use two limits when coding. Lines should fit in 80 columns after the initial indentation. Reading a column of text wider than that is f

      • by HiThere ( 15173 )

        Well, except that some card readers wouldn't read anything past column 72. The last few columns were intended for sequence numbers, so that if you dropped your deck you could put it back in the correct order. And, of course, the first 5 columns were intended for labels so that you could go to the proper place when you branched. And the 6th column was intended for a continuation marker, in case your statement wouldn't fit on one card..... A lot of arbitrary choices there. If you were using cards as your

        • What you wrote is mostly applicable only to program cards, not data cards where only the sequence numbers take away from the total number of available columns. Of course, this whole conversation has to do with programs, making it relevant.
      • How about, can you fit a line of code into a book or manual? I know not a lot of people do it, but it's a good rule of thumb. Notice that by default when you create a text document that you do not get arbitrarily sized virtual pages. There's a limit. 8-1/2x11 for Americans, similar proportions internationally. If the code doesn't even fit when you go landscape that way, then it's almost certainly going to be more difficult to read no matter what you do with it.

        I know people who used to do this, they'd

    • Re:Sense at last (Score:4, Insightful)

      by mattyj ( 18900 ) on Sunday May 31, 2020 @05:14PM (#60129074)

      Lemme educate you, son.

      The 80 column limit is by no means arbitrary, or a mistake. Back before you were born, in the dark ages before RGB, terminals had 80 columns, thus coding style locked into that column width. For a long time, word wrap wasn't even a thing. (some coding languages and shells to this day use a backslash to denote a continued line, that's why.)

      Eighty columns is legacy, maybe even tradition, for sure, but not at all arbitrary. (I don't have space/time/desire to explain 'why 80', but the info is out there if you seek it.)

      If you're still programming in a terminal then you're a weirdo, but the limit is no more arbitrary than other standards, current or outmoded, like 24 fps standard for filmed motion pictures, 4:3 ratio of broadcast TV, or the number of scanlines on a 4k display. All of this stuff is at the intersection of technological limitations, standardization and budget at the time these things were originally being worked out.

      • At a company I worked for, I changed the coding standard to 164, because that was how many could fit on a landscape printout, as we were required to do code reviews in meetings with printouts.

        My current company has a 132 length, completely arbitrary but usually sufficient except for comments and generated tables, which can gat rather large with longer symbols.

    • Linus also mentioned (right there in the summary) that it's not a hard limit precisely for the reasons you mentioned. He'd prefer descriptive variable names as opposed to shorter line lengths. I agree that it makes much more sense as a guideline.

      And longer lines are simply useful. Part of that is that we aren't
      programming in the 80's any more, and our source code is fundamentally
      wider as a result.

      Yes, local iteration variables are still called 'i', because more
      context just isn't helpful for some anonymous counter. Being concise
      is still a good thing, and overly verbose names are not inherently
      better.

      But still - it's entirely reasonable to have variable names that are
      10-15 characters and it makes the code more legible. Writing things
      out instead of using abbreviations etc.

      I also found it mildly humorous that his post was formatted to fit in 70 columns.

    • by AmiMoJo ( 196126 )

      Still with 8 space tabs though... Linus claims it's for readability but I don't have any problem following indents with 4 character tabs. Do other people?

      • by lgw ( 121541 )

        Nah, some people just can't let go of what was right in the 80s. I use 3 space tabs when I have a choice in managed languages, as almost all your code is indented at least twice and it's wasteful. I tried 2 space tabs, and for me that's where it starts to get a little visually fatiguing to keep the indent level straight.

      • by HiThere ( 15173 )

        Personally, I usually use tabs for indentation, and I have my tabs set for 3 spaces in the editor. If indentation starts getting too deep, I can set them to 2 spaces without impairing readability much. 1 space, however, loses all merit.

        • Personally, I usually use tabs for indentation, and I have my tabs set for 3 spaces in the editor. If indentation starts getting too deep, I can set them to 2 spaces without impairing readability much. 1 space, however, loses all merit.

          For the sake of others, PLEASE don't use Tabs for white space, use spaces for white space. Please?

          The problem with tabs is that it's not the standard to put tabs in as a constant number of spaces, so when somebody else pulls up your Tab laced code into their editor, it may or may not "line up" as you expected. If they have tabs set to say 8 characters wide, then it makes that line you so dutifully limited to 80 chars that's indented a few times longer than 80 forcing the editor to wrap it (or the display

      • I use 4 columns for my own stuff, but 3 for work because that's the "standard" there. I can read either without difficulty, but I prefer the extra visual space 4 columns gives me.

    • by ras ( 84108 )

      it's a totally arbitrary value

      Yes, it is. But it's it's an arbitary value trying to solve a real underlying issue: lines that are too long are a PITA. At the extreme lines several thousand characters line (and yes, I've seen that in PHP scripts) are very difficult to read and utterly unnecessary. Any coding style guide should ban them, and all I've seen do.

      But what line length is acceptable? I can give you one good place: when you can't see the entire line. I've seen quite a few programming errors caus

    • it's a totally arbitrary value...[t]he intention was to produce readable code that can be viewed and understood

      It's actually an obsolete artifact of earlier technology. Line limits made sense when you were feeding your programs into the machine with punch cards. Now, not so much. Also, back in the dark ages, the amount of storage your source code took up was actually a significant cost factor.

    • }}} People end up choosing bad variable names as otherwise the lines get too long. ((( --- The problem you highlight is not the line length. The problem you highlight is programmers who choose not to write readable, maintainable code. I've seen excellent code written within the 80 character line length. I've also seen some pretty horrendous code written without concern for line length. The problem is not the line length.
  • by fahrbot-bot ( 874524 ) on Sunday May 31, 2020 @04:46PM (#60128988)

    ... the checkpatch.pl script that checks patches to no longer have a max line length of 80. Instead, the check patch script is using a maximum line length of 100.

    Seriously?

    Sign, I must not be nerdy enough for this to be news here on /.

    • ... the checkpatch.pl script that checks patches to no longer have a max line length of 80. Instead, the check patch script is using a maximum line length of 100.

      Seriously?

      Sign, I must not be nerdy enough for this to be news here on /.

      Or not old enough to have recognized the onset of presbyopia - the first symptoms of irreversible body degradation due to age. Its onset typically becomes noticeable about 40 to 42, is pretty much universal by 45, and worsens until about 65.

      For most things it's an annoyance.

  • by paralumina01 ( 6276944 ) on Sunday May 31, 2020 @04:50PM (#60129002)
    I remember reading him write how 80 characters was enough, and that it is only a case that matters when people are nesting multiple scopes (specifically more than 3) that are the ones that have a problem and they need to program better.
    • by AmiMoJo ( 196126 )

      It depends on style too, if you indent case statements then you are already three tabs in (function, select, case) which means very limited logic it a bunch of function calls.

      Some people like to save vertical space with if statements that put everything on one line, but that makes them harder to follow in most debuggers.

      Best solution is to buy a bigger screen, which fortunately is really cheap now.

      • by lgw ( 121541 )

        Single line if and case statements do make sense in a specific context though: where you have a bunch of structurally identical statements in a row, with only 1 value being different. That is, explicit mapping from input to output where you can't use array lookup, or a computed jump is faster.

  • by the_skywise ( 189793 ) on Sunday May 31, 2020 @04:51PM (#60129006)

    Explains a lot... wonder if it was green or amber... probably amber...

    Seriously tho - I've encountered this in Python recently as its a PEP guideline to keep your lines under 80 characters. Real pain in the butt when you've indented a few times and really hated it at first coming from Java/C++ where I'd rack up an offscreen line easily (i mean, c'mon, it's a function call with a dozen parameters - I'm not going to put them all on a separate line!). But with mucking around Python long enough I've come to agree that seeing all the code on screen at once is really "a good thing"(tm). I still think 80 characters is too short but probably anything over 132 is too long.

    My 2 cents anyway.
    (and don't get me started with treating tabs as functional operators!)
    (tabs, of course, should 5 spaces as God intended with the typewriter)
    (now get offa my lawn!)

    • The adoption of such line limits by other languages/projects is interesting. I'm of the opinion it's the same sort of logic mistake that drives lots of marketing - 'Linus writes great code. Linus likes 80 character line lengths. If I use 80 character line lengths, i'll code like Linus' (hint, no you won't).

    • Maybe languages shouldn't rely on hard indentations? I'm a hardware guy and Python seems like such a pain in the ass to deal with. Oops one extra space on this line and the whole thing dies. The compiler doesn't care about whitespace.

      • I do mostly embedded stuff in C, but I do enough other stuff in Python that I've gotten used to the indentation thing. It's still kind of a pain in the ass, but it doesn't make me want to hurl the keyboard across the room like it used to. I guess I've got a bit of Stockholm syndrome going on.

  • Of course I'm saying this because I've been coding with 100 column x 56 row editors for a few years now ;^)

    More seriously, there should be a discussion as to what is too much information on a line of code. The goal should be to maximize ease of understanding the code versus having to add comments to explain what's happening.

    For example, which is more readable, this:

    if ((0 != columnOffset) && (0 == (xCoord & 0x80000000)) {

    or

    if ((0 != columnOffset) &&
            (0 == (xCoord & 0x80000000)) {

    The condition is true if the column is not zero and the x coordinate is zero or positive - which line conveys that message better?

    • by shess ( 31691 )

      Neither is going to compile, and neither is close enough to 80 columns to matter much.

      0 == (xCoord&0x80000000) is something I'd flag, regardless, because nobody is checking whether that on bit is in the correct location for the test you intend. Did you place enough zeros? Is xCoord the size of integer you're assuming it is? Is 0x80000000 the same size of integer as xCoord? It's not 1988 any longer, we can do better than this. Personally, I'd suggest !(xCoord 0) and let the compiler figure it out.

    • Having the constant first when using a comparison operator is new to me. But I believe when using multiple lines, it's a lot easier to move the eyes up and down versus left and right.
      • Having the constant first when using a comparison operator is new to me....

        I adopted that habit years ago specifically so this would generate a syntax error instead of inadvertently becoming an always-true assignment.

        if (7 = x) {

      • by lgw ( 121541 )

        In th bad old days, compilers wouldn't warn you when you did

        if (x = 57)

        But you meant

        if (x == 57)

        So putting the constant first became a habit. Back in the 1980s, that sort of shit made sense. Hasn't made sense in a long time now, and just makes code harder to read, but some people just can't let go of 80s coding styles.

        • by Kjella ( 173770 )

          There's still ways of triggering the same issue. Much like the definition of kilo I wish they'd left the "equals" operator from math alone and done it VB-style like x := 57 (but keep it as x == 57). Most code of any significance is read far more often than it's written.

        • It's fine that most if not all compilers nowadays will flag that with a warning, but during code reviews you generally aren't compiling the code, and don't have a guarantee that the coder didn't just ignore the warning. It's just as easy to miss an accidental assignment during a review as it is when you're writing code, so there is still a benefit to doing it the other way, and if you're used to that style it's not any harder to read.

    • by AmiMoJo ( 196126 )

      Is there any good reason to not use the greater than operator for checking greater than zero here? The compiler should optimise it well and there is no chance of missing a zero in your rather big constant.

      Maybe xCoord is unsigned? Casting to signed can look a bit messy I guess.

  • People with restrictive hardware shouldn't make it more inconvenient for people who have better resources...

    So those with money get to stick to those who don't? Why does that sound familiar?

    • by arcade ( 16638 )

      I've defended 80x25 for many, many years. However; it was the standard 20 years ago and was probably a bit dated back then, and honestly, we've moved on.

      I've got relatively crappy hardware, but when I just expanded my xterm to the edge, echo $COLUMS returned 320.

      I'd be fine with accepting I'm probably affluent, and go for half that. Going for just 100 seems a bit restrictive, and I'll argue for 160 character line length as probably entirely OK.

    • Technology advances. If you're still using a 4:3 or 5:4 aspect ratio display in 2020, for example, it's time to change since most software assumes people are using at least a 16:9 or 16:10 aspect ratio display.

      I do understand that if it's possible, software should support whatever aspect ratio your monitor is (from 4:3 to 32:9, for example) but sometimes older technology just doesn't fit with modern needs. I know it doesn't sound like a nice thing to say, but people with older hardware can't delay progress.

    • Comment removed based on user account deletion
  • Especially in the case of functions that take many arguments, splitting the call or even the declaration to one argument per line allows a short comment to identify each one and explain something about it in each invocation.
  • now what am I going to do?

  • People with restrictive hardware shouldn't make it more inconvenient for people who have better resources...

    Or, as we put it over here in the first world, your poverty makes me puke.

    • by godrik ( 1287354 )

      I agree with you in general. But in this particular case I think Linux is right. He is talking about some prehistoric machine right there. My laptop is standard issue in my university and that is the model (Dell Latitude E7250) that we are starting to replace because it is out of warranty. And it is a 4-core system with 16GB of ram (I may have gotten the upgraded model because I do performance).

      I am all for accessibility, but you would expect kernel contributors and people who frequently compile the kernel

  • OK, you can go to 132 characters if you must

    [for those who don't remember the dim past, 132 characters was the width of the "super-wide" IBM 3270-type terminal; never really replaced the true 80-column 3270 though]

    • by lgw ( 121541 )

      heh, someone else does use 132. More commonly, 132 was the width of wide printer paper, of the kind used to review code in the old days. 132 characters was a good limit for shops with better text editors, but that still used paper copy for review and sign off.

  • Come on now, vt100 supported 80 and 132 for decades and so any terminal should have been capable of 132 chars and especially on GUI based desktops.
    And easily the graphic displays of the '90s supported 132 char views.

    This is like FAT and should have been dead long ago.

    LoB
  • Iv'e been programming (er "coding") for over 40 years now. I've done plenty on 80x25 green/amber/white screens, and up to 132 columns on DECwriters, Teletype 43s and the like. Because that's the hardware we had then.
    But we've been using large wide LCD screens for two decades now, and the self-imposed limit makes no sense at all. What the heck is people's aversion to using the middle and dare I say over to the right side of the screen? My editor can reformat and do all sorts of fancy stuff for me, so have
  • by lkcl ( 517947 ) <lkcl@lkcl.net> on Sunday May 31, 2020 @05:50PM (#60129212) Homepage

    i was taught at university - interestingly not by the professors but by a lab assistant - that if you cannot see the purpose of a function clearly written on one terminal, then fundamentally there is something wrong with the code. that if you have gone beyond the indentation level to the point where the code wraps around, this is a straight simple indication that you need to break the code down into functions.

    i have followed these rules for 30 years and found that they serve projects extremely well.

    over that time, screen sizes have increased drastically, from 800x600 to 1024x768, then to 1280x1024, 1600x1200, 1920x1080 and now finally 4k screens. throughout that time, i have *always* kept terminals at 80x60 - or now with a 4k screen, 80x70. this allows me to do things like this:

    https://libre-soc.org/HDL_work... [libre-soc.org]

    that's a whopping *ELEVEN* visible 80x70 xterms, another three of which are temporarily obscured by a graphviz display, nine of which are in active use at the time that the screenshot was taken.

    how the hell can you have *nine* active xterms in use at one time? it's very simple: seven of them have code open, and two of them have commands running. one of those commands is a stack-trace of the application being debugged, and the one next to it contains important command-history of yosys (controlling the display of the graphviz).

    each one of the *seven* active editing windows - each where every single line of code respects an 80 character limit (with the exception of 3rd party code) - provides vital information about the bug being investigated. they fall into the following categories:

    * files being edited that functions are being added to
    * files that those functions *use* (immediate-use)
    * commonly-used library routines

    often in some cases i will have 1200x800 browser windows - two stacked one under the other - next to EIGHT 80x65 xterms, particularly when doing internet research. in others, i will have PDFs side-by-side with the code being edited.

    what benefits are there by having such a huge amount of information on-screen? the question itself contains the answer: "huge amounts of information". it turns out that having the files being edited next to the files containing the functions that they use, means that i am not flipping back and forth constantly, trying desperately to memorise the header file, or trying desperately to recall what the function parameters are of the subroutine that i want to call, because that subroutine's definition is right there, right in front of me.

    bottom line: i don't have to memorise millions of lines of code in order to maintain complex state information in my head: i can see it all, right there, at a glance.

    and this is where Linus Torvald's statements become problematic. he's forgotten that not everyone has a working mind-map of the linux kernel codebase in their head. tools such as emacs split-windows, ctags, and IDEs with "Mouse-over" hints that show the definition of the function being called are *not enough* when it comes to massive multi-million-line codebases.

    80x65 terminals fundamentally forces developers to break code down into smaller chunks that fit on the screen. with multiple such chunks being visible at once, newcomers and seasoned developers alike can not only keep track of complex code, they are much less likely to write code that requires memorisation of state and context spanning vast swathes of text that cannot be displayed on any screen, let alone a single 80x65 terminal.

  • But ... (Score:5, Funny)

    by PPH ( 736903 ) on Sunday May 31, 2020 @06:01PM (#60129240)

    I
    get
    paid
    per
    line
    of
    code
    .

  • My line length is basically dictated by how many characters I can fit on a line in an emacs frame split into two. Programming with two files open is the most common case for me, and everything follows from that. The only problem is that as I get older I like the font to be bigger so Iâ(TM)m starting to lose line real estate.

  • . . . 80 is far too long. 72 FTW.
  • by kenh ( 9056 ) on Sunday May 31, 2020 @06:24PM (#60129316) Homepage Journal

    I can only imagine the head-smacking Linus did, sitting down in front of his shiny new $8,000, 64 thread/32 core desktop with 256 Gig of RAM and wondered wy he had to stare at little 80 column windows on his 40" curved QHD display?

    He probably had been looking at 80 column code lines since he first coded his little kernel on his new 80386 desktop back in the day...

  • Most of us have escaped the constraints imposed by Hollerith cards.

  • I hate character line limits that are present for no other reason then be a pain in the ass. Well I can admit that I rarely have a line over 80 characters, there are a few in my the platform that are 100 or more. I've heard some insane individuals prefer to do code reviews on limiting hardware to simply impose pointless restrictions
  • by kenh ( 9056 ) on Sunday May 31, 2020 @06:39PM (#60129366) Homepage Journal
    C doesn't care about white space characters, and has no need for continuation characters, just keep typing - that why we can have fun things like the Obfuscated Code in C Contest:

    #include <stdio.h>
    #define  f(f,g){z e=0;for(;e<f;e++)g;}
    #define  i(f,g)static z f(z a){return g;}
    #define  j(f,g)static void f(z*a,z*b,z*c){g}
    #define  h(f,g)static z f(z a,z b,z c){return g;}
    #define  g(f,g,h,i,j)static z f(z b){z a=g,c=h;for(;i)a=j;return a;}
    typedef unsigned char y;typedef unsigned long long z;extern y*w;static z b(z a,z b){return a>>b|a<<(64-b);}i(_,
    (a>>6)^b(a,61)^b(a,19))i(_a,b(a,39)^b(a,28)^b(a,34))h(x,((a^b)&c)^(a&b))i(u,b(a,41)^b(a,18)^b(a,14))h(t,(((((3*(a*c+b*b)>>9)+(3*
    b*c>>32))*a>>21)+(3*a*a*b>>6)+((b>>4)*(b>>4)*b>>46))>>18)+a*a*a)h(m,t((b<<16)|(c>>48),(c>>24)%(1<<24),c%(1<<24))>>48<a)h(s,(a&b)
    ^(~a&c))i(r,b(a,1)^b(a,8)^(a>>7))g(o,0,0,c<8;c++,a*256+w[b*8+c])g(d,0,0,c<13;c++,a*31+w[b*13+c]-96)g(p,0,4,c;c/=2,a|c*m(b,a|c,a)
    )g(q,0,1ull<<63,c;c/=2,a|c*m(b,p(b),a|c))g(v,b>1,2,c<b;c++,a&&b%c)g(l,b?l(b-1)+1:2,a,!v(c);c++,c+1)j(n,z d=a[7]+u(a[4])+s(a[4],a
    [5],a[6])+q(l(*b))+c[*b%16];f(8,a[7-e]=e-3?e-7?a[6-e]:d+_a(a[0])+x(a[1],a[2],a[3]):d+a[3])f(16*(*b%16>14),c[e]+=c[(e+9)%16]+r(c[
    (e+1)%16])+_(c[(e+14)%16])))j(k,f(8,b[e]=a[e])f(80,n(a,&e,c))f(8,a[e]+=b[e]))int main(){z a[8],b[8],c[16];f(8,a[e]=d(e))f(16,c[e
    ]=e-15?o(e):d(8))k(a,b,c);f(16,c[e]=e?e-15?0:11264:1ull<<63)k(a,b,c);f(8,printf("%016llx%s",a[e],e-7?"":"\n"))return!w;}y*w=(y*)
    "crsmyiajqhwy{unwa|hjoi`hlxhpxrzb~edko~rtr~ileqyjk`znqgsuitvgqnfdfa||wedvnmhozkpokootqzcexeld~oibqzpcsuw{ib{x`m`hsa`jmn}wcfzpb";

    I didn't count, but that looks like about 80 characters wide, and it certainly doesn't use "space" characters to indent, so it's all good, right?
  • by coats ( 1068 ) on Sunday May 31, 2020 @06:40PM (#60129372) Homepage
    On the other hand, it is well established by the human-factors people that text is most readable if the effective line length -- from the first non-blank character in the line to the last non-blank character -- is at most 70 characters.

    Those web pages that wrap paragraphs into 150-character lines drive me nuts. I refuse to read them as-is; they are in fact one of the major reason for "reader" extensions to web-browsers. Before these came into common availability, I wished I could punish the web-authors that did such things -- severely!

  • by argStyopa ( 232550 ) on Monday June 01, 2020 @07:34AM (#60130652) Journal

    ...that we're having a discussion about shitty, primitive formatting on Slashdot.

It is not best to swap horses while crossing the river. -- Abraham Lincoln

Working...