Is the 80 character limit still relevant in times of widescreen monitors? [closed]

Question

on a widescreen monitor one can easily see more than 80 characters at a time, without scrollbars. even linus torvalds sees the 80 character limit as outdated.

so, is the 80 character limit still relevant in times of widescreen monitors?

Answer 1

There are several reasons to still adhere to an 80 character limit (or, a 74 character limit is even better; it allows for the code to remain fewer than 80 columns even when diff markers and email quoting is added, if you do code review on mailing lists).

Even in the era of widescreen monitors, I like to have several windows open side by side, showing different parts of the code. For instance, I usually have a web browser and email open on one screen, and two files and a terminal open side by side on a second monitor. If you have lines that run over 80 columns, you need to deal with the editor wrapping the lines (which is ugly and makes the code harder to navigate around), or widen you windows such that you can't fit as many on screen at once.

Even if you don't usually edit this way, if you ever use a side-by-side diff tool, you will appreciate files with reasonable line lengths which will make your diff easier to view.

There's also an issue of code density. I like to have a lot of context when reading code. It is much, much quicker to glance up and down a window than it is to scroll. If you have very long lines, you also tend to have lines that vary in length a lot, leading to a lot of wasted screen real estate and being able to fit less code on screen at a given time overall.

And finally, if you have very long lines, then that generally means that you have very complicated lines, deep indendation, or that you have very long identifiers. All of these can be a problem. Complicated lines are probably doing too much; if you can break it down into several simpler lines, you probably should. Deep indentation means that you're probably nesting too many loops and conditionals, which can make your code flow confusing; considering refactoring into several functions. And if your identifiers are too long, it can make reading your code very difficult. People generally recognize words as individual units; they don't read every character one by one, but look at the overall shape of the word. Long identifiers are harder to distinguish this way, and usually if they are that long, they contain redundant or repetitive information.

Now, while it's still good practice to keep code below 80 columns, this isn't one of those rules that needs to be followed religiously, contorting yourself to make some line fit when it just doesn't. I suggest that you try to keep all of your code under 80 columns, but when it just doesn't fit, don't worry about it too much.

Answer 2

If I keep my lines to less than about 100 characters, I can have two editor windows side-by-side on a widescreen monitor. It's very useful to have both the class header file and implementation both visible at the same time, or have code on one side that calls into the code on the other. And, if I keep the lines short, I don't need a horizontal scrollbar on my editor windows, which gives me more vertical space.

80 characters may be outdated, but there's some merit in keeping things within reason.

Answer 3

I don't think the monitor has anything to do with it - at least not anymore.

If you can't code a line in 80 characters, that's probably a sign of bad code anyway. Too complex expressions. Too deep indentation. etc. You should stop and rethink what you are doing.

But if you are sure that the code required more than 80 lines, then go ahead and do it. I think it's better to have a code that surpasses the 80 characters than adding idiomatic changes only to make it smaller.

I personally hate this kind of stuff:

ret = my_function(parameter1, \
                  parameter2, \
                  parameter3, parameter4);

Instead of simply:

ret = my_function(parameter1, parameter2, parameter3, parameter4);

Answer 4

To coding?

Certainly yes. Normal human been can't read well too wide. With few columns you move your eyes less, you focus better and delay the tiredness. It's a minimum gain but an important one.

Answer 5

Yes, there are reasons to limit code line length:

1. Although our screens have gotten wide, sometimes you need to print out your code. If only for this reason.
2. Diff-viewers often display lines with a vertical split - this becomes harder if the lines are as long as a wide screen would allow.

Having said that, 80 is a bit too little. But, still, some limitation is probably a good idea as a design principle.

I would say that extra long lines shouldn't be disallowed, because occasionally they are necessary. But if most functions are only viewable on a 30" screen then the code has some issues.

Answer 6

It's arbitrary, but there is a non-arbitrary limit to what is easy to read. I find that super-wide columns of text are very hard to scan and read, regardless of if they are code or prose. Further, as a lot of other answers have pointed out, it's not like this code is going to be the only thing up on your screen. It's great to have two or more windows of code up at the same time, and have them fit on one wide screen monitor.

Answer 7

It is probably not relevant to choose exactly a 80 character limit; what would change if the limit is 85, for example?

It's true that monitors used nowadays have higher resolutions, but in a text editor/IDE, not all the space is taken from the text view; in the editor I use shows to the left side the list of the files included in the project.

The resolution used in a netbook, or a notebook is not the same used in monitors; it probably makes sense to use a character limit that doesn't create "problems" to anybody.

Answer 8

It really depends on the development environment.

For example, in a large corporation with thousands of developers, there are probably hundreds of people who will, over the course of a product's lifetime, have to look at some portion of it's code. With that many people, there's bound to be a few who, for whatever reason (older hardware, netbooks, etc) are operating at 800x600 or smaller. There's some value to accommodating them.

At my 25-person company, though, I say screw it. We're all using dual modern monitors at the maximum resolution- 120-140 or so is the informal guideline.

Answer 9

Having some limit certainly makes sense. But 80 character limit is too constraining. I prefer something like 96 character limit. It's wide enough for most of the code I have to deal with and it's narrow enough so that two files can be put side by side for diff'ing (on a wide screen).

I believe code readability trumps all other concerns. And with 96 characters per line code can be made much more readable than with 80.

I don't buy the argument that most people set their terminals to 80 characters wide, no that printers have to wrap lines longer than 80 characters. It's not a hard limit as it used to be in the (distant) past. You can easily set the terminal and the printer width to 100 characters.

Answer 10

No, it's no longer relevant:

• Most fonts used in applications and on the web aren't fixed-width anyway. In other words, 80 characters != 80 characters.
• As you said, screen widths have changed - 80 characters is not a sensible boundary.

80 characters was really a guideline for fixed-width fonts in a console environment.

Of course, if you're still using a fixed-width font in a console environment... then sure, 80 characters is sensible :)

Answer 11

If you use an editor in a GUI, then the 80 characters per line is irrelevant, since most decent editors - for example Notepad++ - have a button to toggle line wrap. With that, it should not be a problem, even when viewing the code in a thin window.