8 ms·

Can someone shed some light on the reason why we're still bothering with "line is too long" in 2014? I mean I'm not talking 300 characters-long lines here that

Can someone shed some light on the reason why we're still bothering with "line is too long" in 2014? I mean I'm not talking 300 characters-long lines here that's ridiculous, but the idea that a line with 90 characters is "too long" because some arbitrary limit in the width of certain terminal emulators back in the days was fixed at whatever number of columns seems really backwards. So yeah, I'm open too any sane explanation of the why that is actually good practice beyond what I perceive as severe cargo culting.

crazygringo 13y ago
Because you either have to decide on a number, or else implement automatic wrapping, and automatic wrapping can be bad for a number of reasons (which I won't get into here). As long as you decide on a number, you want to pick something that is wide enough to be useful, but small enough that it doesn't lend itself to abuse (overly long variable names, 8 levels of indentation, and so on). Also, it's nice to be able to look at two or three columns of code in a reasonable font size on your monitor, to view it in websites of normal width, and so on. And to know that you can still view code just fine on your 11" Macbook Air, even with a project-tree sidebar open in your editor. For legibility, typeset columns are often recommended to contain something around 60 characters per line, although there's clearly a range. [1] Because code is often indented 1-4 levels (unlike normal text), it makes sense to expand this somewhat, and 80 is a nice round number for this. So, 80 is probably the most common number I've seen for code line length, and there's absolutely nothing cargo-cult about it. It's simply that, if you don't want to implement line-wrapping, you need to pick something, and 80 is quite reasonable. [1] http://en.wikipedia.org/wiki/Column_(typography) http://en.wikipedia.org/wiki/Column_(typography)
jjgreen 13y ago
500 years of typographical practice has shown our species that 80 characters is about as long as a line can be before it becomes difficult to read. To see this, take a novel from your bookshelf and count the characters per line.
- ceejayoz 13y ago
  Sure, but nothing says you can't shrink your text editor's window down to 80 characters wide if you like.
  - solox3 13y ago
    Are you talking about line wrapping? Because I don't know a single person who enjoys wrapped lines of code.
russianbandit 13y ago
A lot of developers use vim, with split buffers. When code lines wrap, they look ugly.
- psychometry 13y ago
  But other text editors handle long lines perfectly well. I don't think other developers' choice of tools should dictate coding styles. I exclude the tab/spaces debate from this because it has ramifications outside of mere stylistic concerns.
  - scott_karana 13y ago
    There are only two possible ways to deal with long lines extending past the edge of the window. 1. Scroll off the side of the window Pain in the ass. Ever try diffing a file, and had to scroll? 2. Wrap Also a pain in the ass. Formatting alignment, confusion over where important linebreaks are, etc.
    - roryokane 13y ago
      3. Wrap, and use a good editor Many editors don’t fully support soft wrapping, sadly. But if you’re lucky enough to use an editor that includes the necessary features, there are no problems with soft wrapping. Soft wrapping has the advantage that you never have to manually re-wrap a line. These editor features make soft wrapping useable: Display noneditable symbols at wrap points to mark them as nonimportant linebreaks. In Vim, `set showbreak=->` to display “->” at wrapped lines. Emacs supports putting arrow symbols in the “fringe”. Visual Studio has a preference to enable this. Indent wrapped lines at the same indentation as the start of the line, optionally plus extra indentation. Vim does not support this but there is a patch for Vim that makes this enable-able with `set breakindent`. Coda supports it fully, with customizable extra indentation. This is the least-supported, most-important feature of making wrapping useable. Separate logical-line movement and visual-line movement. Pretty much every editor supports this. Logical-line movement is really only necessary in macros, anyway. In Vim, it’s j/k (or -/<Enter>) vs gj/gk. In Sublime Text, it’s up/down vs option-up/option-down (or some combination like that).
LargeWu 13y ago
It goes farther back than terminal emulators. the old IBM punchcards physically only had room for 80 characters. I'm with you, though. 80 characters is really short, especially if you are indented more than a few stops. It also discourages descriptive variable/method names, which harms readability of code far more than slightly longer lines.
- russianbandit 13y ago
  80 characters is thoughtbot's style. You can always configure it to be some other number, or turn in off altogether.
- salbertson 13y ago
  Here's an example of how you could configure Hound to increase the line length limit. https://gist.github.com/salbertson/d5eb2d42f68df9e18d10 https://gist.github.com/salbertson/d5eb2d42f68df9e18d10
- mjcohen 13y ago
  I like to indent two characters per level of indentation. If the indentation uses braces, I indent one for the brace and one more for the code.
nimblegorilla 13y ago
Two reasons: 1: My 15" screen is about 160 characters at my preferred font size. When I want split screen to compare two files then each one should only be about 80 characters. There is even less space when using IDEs or text editors that include file drawers or other widgets. 2: Excessive characters on one line is a code smell just like excessive line counts in one method. You agree that 300 characters is too much. If 90 is too little then at what point should an automated tool trigger a warning?
- VeejayRampay 13y ago
  Well, the problem really stems for what you call a "code smell". All the good practices about programming will mention that: 1) Excessive line count in a method is a code smell 2) Excessive number of characters is also a code smell 3) Non descriptive variable names are universally considered bad practice. Now my problem with all this dogma is that if you combine 1, 2 and 3, you're left with a severe conundrum. And to me, excessive number of lines in a method and naming your variables a,b,c,d,e are concessions that I prefer to avoid if I can simply crank up the number of characters on a line (taking into account indentation caused by conditionals, method definitions, blocks, etc).
  - PeterisP 13y ago
    (1) (2) (3) can all coexist : First you fix (3), by naming variables in a nice, descriptive way - that possibly causes violations of (2). Then you fix (2), by having lines/statements that are clear and don't do ten things at once - that possibly causes violations of (1). And then, you fix (1), by refactoring your methods properly - and that is a valid goal by itself. If instead you have longer lines, then the problem of your method being too big doesn't go away, it still does the same thing, you just don't notice it. If (1)+(2)+(3) would force you to split up your methods, then that's an indication that those methods should be split up anyway, even if you choose to ignore (2) and (3) - "too many lines of code" is a code smell simply because it correlates to "does too much", and even a one-line method can possibly be doing too much, if it's written in code-golf-style.
akerl_ 13y ago
We had to pick an arbitrary point, and 80 had enough history to make it common. I definitely pass 80 characters when it makes sense, and I use the appropriate pragmas to make rubocop understand not to warn me. But for the most part, 80 characters as a limit helps me know when my lines are getting to long.
rubiquity 13y ago
Back when I worked on a project with Thoughtbot I used to fight with them about this all the time :) 80 characters felt really restraining on anything but an 11inch MacBook Air. Limiting your ability to have descriptive names is a huge loss just to mindlessly follow some line convention from decades ago. I tend to like restraint, but when restraint is at odds with communicating to future developers I can't side with it. These days I try to keep lines 130 characters or less, likely just as random a number but at least more forgiving.
- salbertson 13y ago
  Whatever works for you, just configure Hound to comment on lines longer than 130 instead of 80. https://gist.github.com/salbertson/d5eb2d42f68df9e18d10 https://gist.github.com/salbertson/d5eb2d42f68df9e18d10

crazygringo 13y ago

Because you either have to decide on a number, or else implement automatic wrapping, and automatic wrapping can be bad for a number of reasons (which I won't get into here). As long as you decide on a number, you want to pick something that is wide enough to be useful, but small enough that it doesn't lend itself to abuse (overly long variable names, 8 levels of indentation, and so on). Also, it's nice to be able to look at two or three columns of code in a reasonable font size on your monitor, to view it in websites of normal width, and so on. And to know that you can still view code just fine on your 11" Macbook Air, even with a project-tree sidebar open in your editor. For legibility, typeset columns are often recommended to contain something around 60 characters per line, although there's clearly a range. [1] Because code is often indented 1-4 levels (unlike normal text), it makes sense to expand this somewhat, and 80 is a nice round number for this. So, 80 is probably the most common number I've seen for code line length, and there's absolutely nothing cargo-cult about it. It's simply that, if you don't want to implement line-wrapping, you need to pick something, and 80 is quite reasonable. [1] http://en.wikipedia.org/wiki/Column_(typography) http://en.wikipedia.org/wiki/Column_(typography)

jjgreen 13y ago

500 years of typographical practice has shown our species that 80 characters is about as long as a line can be before it becomes difficult to read. To see this, take a novel from your bookshelf and count the characters per line.

ceejayoz 13y ago
Sure, but nothing says you can't shrink your text editor's window down to 80 characters wide if you like.
- solox3 13y ago
  Are you talking about line wrapping? Because I don't know a single person who enjoys wrapped lines of code.

russianbandit 13y ago

A lot of developers use vim, with split buffers. When code lines wrap, they look ugly.

psychometry 13y ago
But other text editors handle long lines perfectly well. I don't think other developers' choice of tools should dictate coding styles. I exclude the tab/spaces debate from this because it has ramifications outside of mere stylistic concerns.
- scott_karana 13y ago
  There are only two possible ways to deal with long lines extending past the edge of the window. 1. Scroll off the side of the window Pain in the ass. Ever try diffing a file, and had to scroll? 2. Wrap Also a pain in the ass. Formatting alignment, confusion over where important linebreaks are, etc.
  - roryokane 13y ago
    3. Wrap, and use a good editor Many editors don’t fully support soft wrapping, sadly. But if you’re lucky enough to use an editor that includes the necessary features, there are no problems with soft wrapping. Soft wrapping has the advantage that you never have to manually re-wrap a line. These editor features make soft wrapping useable: Display noneditable symbols at wrap points to mark them as nonimportant linebreaks. In Vim, `set showbreak=->` to display “->” at wrapped lines. Emacs supports putting arrow symbols in the “fringe”. Visual Studio has a preference to enable this. Indent wrapped lines at the same indentation as the start of the line, optionally plus extra indentation. Vim does not support this but there is a patch for Vim that makes this enable-able with `set breakindent`. Coda supports it fully, with customizable extra indentation. This is the least-supported, most-important feature of making wrapping useable. Separate logical-line movement and visual-line movement. Pretty much every editor supports this. Logical-line movement is really only necessary in macros, anyway. In Vim, it’s j/k (or -/<Enter>) vs gj/gk. In Sublime Text, it’s up/down vs option-up/option-down (or some combination like that).

LargeWu 13y ago

It goes farther back than terminal emulators. the old IBM punchcards physically only had room for 80 characters. I'm with you, though. 80 characters is really short, especially if you are indented more than a few stops. It also discourages descriptive variable/method names, which harms readability of code far more than slightly longer lines.

russianbandit 13y ago
80 characters is thoughtbot's style. You can always configure it to be some other number, or turn in off altogether.
salbertson 13y ago
Here's an example of how you could configure Hound to increase the line length limit. https://gist.github.com/salbertson/d5eb2d42f68df9e18d10 https://gist.github.com/salbertson/d5eb2d42f68df9e18d10
mjcohen 13y ago
I like to indent two characters per level of indentation. If the indentation uses braces, I indent one for the brace and one more for the code.

nimblegorilla 13y ago

Two reasons: 1: My 15" screen is about 160 characters at my preferred font size. When I want split screen to compare two files then each one should only be about 80 characters. There is even less space when using IDEs or text editors that include file drawers or other widgets. 2: Excessive characters on one line is a code smell just like excessive line counts in one method. You agree that 300 characters is too much. If 90 is too little then at what point should an automated tool trigger a warning?

VeejayRampay 13y ago
Well, the problem really stems for what you call a "code smell". All the good practices about programming will mention that: 1) Excessive line count in a method is a code smell 2) Excessive number of characters is also a code smell 3) Non descriptive variable names are universally considered bad practice. Now my problem with all this dogma is that if you combine 1, 2 and 3, you're left with a severe conundrum. And to me, excessive number of lines in a method and naming your variables a,b,c,d,e are concessions that I prefer to avoid if I can simply crank up the number of characters on a line (taking into account indentation caused by conditionals, method definitions, blocks, etc).
- PeterisP 13y ago
  (1) (2) (3) can all coexist : First you fix (3), by naming variables in a nice, descriptive way - that possibly causes violations of (2). Then you fix (2), by having lines/statements that are clear and don't do ten things at once - that possibly causes violations of (1). And then, you fix (1), by refactoring your methods properly - and that is a valid goal by itself. If instead you have longer lines, then the problem of your method being too big doesn't go away, it still does the same thing, you just don't notice it. If (1)+(2)+(3) would force you to split up your methods, then that's an indication that those methods should be split up anyway, even if you choose to ignore (2) and (3) - "too many lines of code" is a code smell simply because it correlates to "does too much", and even a one-line method can possibly be doing too much, if it's written in code-golf-style.

akerl_ 13y ago

We had to pick an arbitrary point, and 80 had enough history to make it common. I definitely pass 80 characters when it makes sense, and I use the appropriate pragmas to make rubocop understand not to warn me. But for the most part, 80 characters as a limit helps me know when my lines are getting to long.

rubiquity 13y ago

Back when I worked on a project with Thoughtbot I used to fight with them about this all the time :) 80 characters felt really restraining on anything but an 11inch MacBook Air. Limiting your ability to have descriptive names is a huge loss just to mindlessly follow some line convention from decades ago. I tend to like restraint, but when restraint is at odds with communicating to future developers I can't side with it. These days I try to keep lines 130 characters or less, likely just as random a number but at least more forgiving.

salbertson 13y ago
Whatever works for you, just configure Hound to comment on lines longer than 130 instead of 80. https://gist.github.com/salbertson/d5eb2d42f68df9e18d10 https://gist.github.com/salbertson/d5eb2d42f68df9e18d10