[VeejayRampay]

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]

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)

[nimblegorilla]

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]

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]

(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.

[LargeWu]

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.

[mjcohen]

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.

[salbertson]

Here's an example of how you could configure Hound to increase the line length limit.

https://gist.github.com/salbertson/d5eb2d42f68df9e18d10

[russianbandit]

80 characters is thoughtbot's style. You can always configure it to be some other number, or turn in off altogether.

[rubiquity]

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]

Whatever works for you, just configure Hound to comment on lines longer than 130 instead of 80.

https://gist.github.com/salbertson/d5eb2d42f68df9e18d10

[jjgreen]

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]

Sure, but nothing says you can't shrink your text editor's window down to 80 characters wide if you like.

[solox3]

Are you talking about line wrapping? Because I don't know a single person who enjoys wrapped lines of code.

[russianbandit]

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

[psychometry]

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]

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]

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).

[scott_karana]

I've used everything you mentioned except the Emacs one.

They definitely help. I just find it inconvenient to need to scroll, and sometimes arrows don't fit my usage case..

Not the editor's fault in either instance, of course. :-)

[rubiquity]

vim also has tabs. I only use split buffers when I'm using my external monitor.

[russianbandit]

Using split window panes allows me to see more on one screen, without switching contexts (tabs).

[nitrogen]

In .vimrc:

    set nowrap

[astrodust]

Yes, then things are hidden. Brilliant.

[nitrogen]

Only until you scroll.

[akerl_]

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.