Slashdot Mirror


Is the 80 Columns Limit Dead?

Dancing Primate asks: "Reading through the code of co-workers and various open source projects, I'm finding that people are no longer formatting their code to 80 columns. With most people using X and the wide range of non-vi editors, is the 80 column limitation disappearing? Am I the only one who gets grumpy when I do a diff or print code, and it's hard to read?"

7 of 317 comments (clear)

  1. It's been dead a long while. by Spudley · · Score: 4, Insightful

    You've only just noticed, eh? Methinks you've had your head stuck in the sands of the character-based terminal a bit too long.

    The only reason I can think of to keep using 80 character lines now is if you're writing in COBOL (which forces the issue). For anything else, you can either write your lines as long as you need them (if you're programming), or you turn on word-wrap (if you're doing anything else).

    When I say 'as long as you need them', that isn't an invitation to write programs with 700-character lines; I mean, there's still a requirement for a degree of common sense, even for programmers ;), but sticking to 80 characters is truly limiting, especially these days when everyone has screens and editors that are capable of so much more.

    --
    (Spudley Strikes Again!)
  2. Conventions are for the READER, not the author by rossifer · · Score: 4, Insightful

    What kills me is how few people realize that code conventions are not for their own personal readability of the code they write. Code conventions are for the benefit of the tens and possibly hundreds of people who are going to be reading the code well after you've moved on to another position.

    Also, for all of the people who assert that their convention (braces on the next line/end of previous line) is scientifically backed to be more readable than the alternative: most of the time, it doesn't matter nearly as much as consistency and being able to have the whole team agree.

    I happen to be the "conventions nazi" in my office (I was also the "unit test nazi" until we bought a tool that did it better than I could). I'm not an asshole about this issue because I'm a control freak, I'm an asshole because conventions really matter to the long term future of the project.

    The right way to be the "conventions nazi" is to get everyone into a room, get everyone to agree that consistency matters more than personal preference, then go down the list of issues and get some consensus (voting works well) on each one. Lone holdouts may need frequent reminding of the "consistency over personal preference" point. Don't leave the room until you have a set of conventions that (1) keep the code consistent in important ways (2) isn't so huge that nobody could hope to remember them and (3) can be easily supported by the tools commonly used by team members.

    Our convention is 132 characters on a line. Inner classes and Java/C++ class/method/variable naming conventions make 80 characters simply impractical. After trying it for a while, there were so many broken lines that the code was simply less readable. So we changed the convention and even though I was for 80 characters, I'm fairly happy with the improved readability of the code.

    Regards,
    Ross

    1. Re:Conventions are for the READER, not the author by ttfkam · · Score: 3, Insightful

      So tell me. How much should I respect you if I am your boss? You've just told me that despite the myriad choices and possibilities available in programming that you cannot adapt to a simple change in bracing style.

      If it takes you more than a week to get accustomed to a new formatting style, you will forgive me if I doubt your ability to adapt to a new compiler or new editor or new operating system or development library.

      And please stop with the strawman of forbidding polymorphism. Yes, there are moronic shops that forbid certain practices that can be instrumental in solving certain problems. But the parent clearly wasn't talking about those instances. This wasn't a discussion of functionality, it was about aesthetics. Deciding about the amount of whitespace, the capitalization patterns, the bracing style, and the line length do not fall under your diatribe.

      And frankly, if you cannot adapt from

      if (1) {
      }

      to

      if (1)
      {
      }

      to

      if ( 1 )
      {
      }

      or from

      write_file()

      to

      writeFile ()

      to

      Write_File( )

      your problems extend far deeper than your code style.

      The question boils down to, "Which formatting style is best?" The answer is simple: "Whatever everyone else on your team is doing." If you cannot adapt to something as simple as this, you cannot be effective in a team. If you cannot be on a team, you are fundamentally useless to 99% of all projects out there. There are better ways to express yourself in code than through bracing style. If formatting style is the best way you can assert your skills and individuality, what does that say about your skills as a programmer overall?

      Have a nice day.

      --

      - I don't need to go outside, my CRT tan'll do me just fine.
  3. Re:More then 80 columns is fine by Tumbleweed · · Score: 4, Insightful

    Okay, Hulk, that's just dumb. You _want_ indentation to be done via tabs - that way everyone can set the tab to _display_ as as many characters as they want. How many 'spaces' (equivalent) a tab displays should be up to your text editor of choice. The original author can display their tab characters as equivalent to 8 or whatever, and you can view it as 4 or whatever. That's the genius of using tabs for indentation.

  4. Re:huh? by pyrrhonist · · Score: 4, Insightful
    Do you really need line coded that long?

    No, you don't understand. Imagine this:

    1. You log into a machine to check some logs.
    2. You adjust the screen size to read the long lines in the log files.
    3. You realize the you need to change a configuration file.
    4. You run vi to change the file, and it says, "Terminal too wide".
    5. You resize the terminal.
    6. You run vi to change the file, and it says, "Terminal too wide".
    7. You resize the terminal again.
    8. You run vi to change the file, and it says, "Terminal too wide".
    9. You resize the terminal again.
    10. You run vi to change the file, and it says, "Terminal too wide".
    11. You beat the every loving crap out of the Sun box.
    Why the fuck is there a hard limit?!? In summary, I installed vim.
    --
    Show me on the doll where his noodly appendage touched you.
  5. Re:yes it does by Mr.+Slippery · · Score: 3, Insightful
    Why are you printing code in 12 point font?! You can buy reading glasses in any pharmacy/ convenience store for a few bucks, btw.

    If you print and display at a decent size, you won't end up needing reading glasses...

    Don't strain your eyes - you only get one pair.

    --
    Tom Swiss | the infamous tms | my blog
    You cannot wash away blood with blood
  6. Re:huh? by Gumshoe · · Score: 3, Insightful
    Why the fuck is there a hard limit?!? In summary, I installed vim.
    In my early UNIX sysadmin career when I was learning the ropes, I was admonished by my boss when he realised I was using vim instead of vi. His reasoning as far as I could gather was that vi is universal and vim isn't and that I might "learn bad habits" by using vim and "become unstuck" if I ever needed to config a machine that doesn't have vim installed.

    Even in my inexperienced youth I realised that there's a line in the sand between UNIX advocacy and clueless lunacy and that he had crossed it.