Is the 80 character line limit still relevant?

Traditionally, it’s always been standard practice for programmers to wrap long lines of code so they don’t span more than 80 characters across the screen.

This is because, back in the bad old days, most computer terminals could only display 25 rows of 80 columns of text on screen at once. Any lines that were longer would simply trail off out of sight. To ensure this didn’t happen, programmers split up long lines of code so none of them exceeded 80 characters.

Today, however, it’s pretty unlikely that you or anyone will still be writing code on an 80-column-width terminal. So why do we keep limiting our code to support them?

The answer, of course, is that we don’t. An 80 character limit has no relevance any more with modern computer displays. The three-year-old Powerbook I am writing this post on, for example, can easily display over 200 characters across the screen, at a comfortable 10 point font size. That’s two and a half VT100s!

The reason this standard has stuck around all these years is because of the other benefits it provides.

Advantages

Long lines that span too far across the monitor are hard to read. This is typography 101. The shorter your line lengths, the less your eye has to travel to see it.

If your code is narrow enough, you can fit two files on screen, side by side, at the same time. This can be very useful if you’re comparing files, or watching your application run side-by-side with a debugger in real time.

Plus, if you write code 80 columns wide, you can relax knowing that your code will be readable and maintainable on more-or-less any computer in the world.

Another nice side effect is that snippets of narrow code are much easier to embed into documents or blog posts.

Disadvantages

Constraining the width of your code can sometimes require you to break up lines in unnatural places, making the code look awkward and disjointed. This particular problem is worse with languages like Java and .NET, that tend to use long, descriptive identifier names.

Plus, the amount of usable space for code is also by impacted by tab width. For example, if you’re using 8-space tabs and an 80-column page width, code within a class, a method, and an if statement will already have almost a third of the available space taken for indentation.

Alternatives

Why 80? At work, my current project team uses a 120-character limit. We’ve all got 24″ wide-screen LCD displays, and 120 characters seems to be a good fit for our .NET/Visual Studio development environment, while still leaving ample whitespace.

There are a few factors you should think about, however. The average length of a line of code depends on what language and libraries you’re using. C generally has much shorter identifier names, and subsequently much shorter lines than, say, a .NET language.

It also depends on what sort of project you’re working on. For private and internal projects, use discretion. Find out what works best for your team, and follow it.

For open-source projects, or other situations where you don’t know who’s going to be reading your source code, tradition dictates that you stick with 80.

Another possibility is to make the limit a guideline, rather than a concrete rule. Sometimes you might not care if a particular line continues out of sight. A long string literal, for example, isn’t going to cause the end of the world if you can’t see the whole thing on screen at once.

It may sound pedantic, but if you do decide to use something different, make sure everyone knows the rule, and obeys it. When there are unclear or conflicting rules, chaos ensues. You can end up with hilarious games like formatting tennis, where every time a developer works on a piece of code, they first waste time reformatting the whole thing to reflect their own preferred coding style.

Why bother?

Some of you might wonder why anyone would worry about such trivial details like the length of a line of code. And that’s cool. But, if like me, you believe that code isn’t finished until it not only works well, but looks beautiful too, balancing style with practicality is very important.

May 31, 2008

27 Comments

John Keating on June 9, 2008 at 4:58 pm.

Another reason to keep the 80

Jon Hancock on June 9, 2008 at 5:48 pm.

>> The three-year-old Powerbook I am writing this post on, for example, can easily display over 200 characters across the screen, at a comfortable 10 point font size.

I’m very happy for you that you can read comfortably at 10 points. I cannot. I set my text editor to 14 points and when my eyes get tired I bump it up to 16.
You rational is sound only if you have decent eyesight.

Colin Curtin on June 9, 2008 at 6:00 pm.

> This particular problem is worse with languages like Java and .NET, that tend to use long, descriptive identifier names.

I think you could shove just about anything in 80 characters, you’ll just have to use more vertical space. The 80 char limit is a code smell for me.. if I jump into a line after a stack trace and find it’s pushing that boundary, there’s something strange going on — bloat, too much nesting, etc.

codemac on June 9, 2008 at 6:13 pm.

One of the biggest side effects of having an 80 character limit.. or any limit really, especially for coding, is that it forces you to make your lines succinct. When you have a line of code LONGER than 80-100 lines, there is a very good chance you are doing something wrong.

Exceptions come with all rules, but I’ve found not letting lines get out of hand not only helps my code’s logic, but also helps it’s maintainability.

Ludolph Neethling on June 9, 2008 at 6:13 pm.

I personally try to keep my code length to 80 characters max per line, where if I write normal text I let the editor wrap my lines for me.

Another question is do one use tabs’ in source code? I normally find if you used different editors/viewers tabs’ just mess around with your code layout.

Regards,

Wolfgang Schnerring on June 9, 2008 at 6:20 pm.

Yet another reason to keep the 80-character limit is that it faciliates displaying/editing *two* files side-by-side on those large screens of today. I wondered how I ever worked without that once I tried it.

James on June 9, 2008 at 7:08 pm.

> Yet another reason to keep the 80-character limit is that it faciliates displaying/editing *two* files side-by-side on those large screens of today. I wondered how I ever worked without that once I tried it.

Only two? My usual configuration is two 120 char wide consoles and three 80 char wide emacs frames per monitor.

Anonymous on June 9, 2008 at 7:50 pm.

Not everyone’s world is ruled by a mouse

mnarkus on June 9, 2008 at 9:08 pm.

I can view much more chars than 80

but i stick to 80 for many reasons.

It is however not a totally strict rule, sometimes i write a little bit more than 80.

Bob K on June 9, 2008 at 9:22 pm.

The 80 character limit was not due to display width but related to punch cards originally used to enter programs. These had 72 characters for program space and 8 for a numbering scheme (IIRC), in case you dropped your stack of cards when you used a mechanical sorter to reorder them.
As someone who has mild dyslexia I find the use of 80 character line with adjoining comment lines for every line utterly unreadable and generally incomprehensible. Consequently I have evolved a programming style which uses as much line width as possible. I then place my comments at the end of the line so that code and comment can be read as contiguous uninterrupted blocks. Typically this rarely extends line lengths beyond 200 characters which on a pair of hi res 20″ screens means that a code page width is more than 60% of one screen width.
When printing out code I use landscape and the whole effect is extremely efficient and has additional benefits, when analysing code and related comment.
One of the most useful features is that since code is not interrupted by the noise of comment it is easy to see the inherent structure and identify structural errors. Many moons ago I used to teach degree and postgrad CS and directed my own CS research projects. The students were often surprised that by merely looking at the shape of their code I could immediately tell where their programs had errors.
Similarly I often find that MS code I have the misfortune to encounter when restructured to my own layout template is riddled with obvious errors.

vilaca on June 9, 2008 at 10:59 pm.

colunm width makes sense if you intend to print code, sometimes i do

A4 (even in landscape mode) hasnt enlarged has displays did

Yannick Gingras on June 9, 2008 at 11:22 pm.

The 80 characters limit is alive and well. As you mentioned, longer lines are harder to decipher. There is that and the fact the if you allow longer lines, it’s just too tempting to put in a function call three levels of sub-calls arguments. With shorter lines, you assign the sub-calls results to intermediate variables with meaningful names which greatly helps to outline the computation.

But seriously, I end up looking at two or three pages of code side by side really often and this is only doable with short lines. One of the major breakthrough of software development is distributed version control which enables us to branch and merge multiple times on a daily basis. Solving a merge conflict is easier with a 3-way side by side differ like KDiff3 or Meld. You can’t do that with long lines so long lines confine you to a baroque style of development.

Splitting your lines takes just a little more time; branching and merging can make you and order of magnitude more productive.

winter on June 10, 2008 at 12:46 am.

Bob K is right: the 80 character limit comes from the IBM punch card standard which was created in 1928:

http://www-03.ibm.com/ibm/history/history/year_1928.html

Tom White on June 10, 2008 at 1:58 am.

Oddly… all of the web programming I do is in a text console at, you guessed it, 80 characters width. In fact, I do plenty of things – including surfing the web – in text mode with a width of 80 characters. Your average graphic designer is probably near tears at this point, but your average sysadmin is nodding his head in agreement.

Daniel Molina on June 10, 2008 at 2:14 am.

That depends on the language, what are you coding and also the screen and the editor used.

In my case, I respect the 76 fill column standard for certain projects, such as FreeBSD. In other
cases, I respect the 155 column standard fixed for some clients that request their applications in
Java. Similar case with C#.

Editing long lines of code under a vty seems to be uncomfortable…

Peter Michaux on June 10, 2008 at 3:13 am.

For usenet posts it is best to use a 72 character limit as it may be wrapped after that. A 70 character limit ensures that at least one reply can be written without wrapping the code.

dclayton on June 10, 2008 at 10:55 am.

The 80 character line limit has nothing to do with punch cards. They are just two instances of the number “80″ that have nothing to do with each other. Seriously, do you really believe that the inventors of the first TTY monitors cared at all about how a transcribed punch card would look on a monitor? More likely, 80-wide was arrived at due to being evenly divisible by 8 (to facilitate memory mapped character displays) and 10 (to facilitate simple math lookups of the memory mapped display.)

diegoeche on June 10, 2008 at 6:25 pm.

I usually work on a 85 char basis. In some strange situations I break the rule. For me is just a matter of aesthetics, but also is easier to put the breakpoints.

Also. when i use VS or emacs I really like a big font (15, 16) so the limit also increases the readability of the code.

Matt on June 12, 2008 at 6:11 am.

DClayton,

Of course they cared about displaying a transcribed punch card.
What good would their fancy new “monitor” be if you couldn’t display
any of the world’s existing code on it?

As for divisible by 8 and 10, why do you think IBM chose that length
for the punch cards? (of course I’m not at all sure what was the byte
size on the machines the punch cards were designed for.)

Matt on June 12, 2008 at 6:12 am.

…err, I mean “teletype”, not “monitor”.

What good would the teletype be if it couldn’t print out any
of the world’s existing code?

-Matt

James on June 12, 2008 at 10:37 am.

I’ve seen java import statements that have exceeded 80 characters. I personally prefer something larger, so there isn’t any strange wrapping.

Tomas Varaneckas on June 12, 2008 at 5:05 pm.

I totally disagree that limit of 80 characters is no longer relevant. For example, if you are a Java developer and use tools like Eclipse along with laptop or not too big desktop display (1280px width), you won’t get much more than 80 chars in code window because of additional panels (Project Navigator, Outline). Even if you have a huge 30″ Apple cinema display but you still work in a team where someone uses 13″ MacBook, it’s disrespectful to have line length limits like 120 characters.

Micah Elliott on June 13, 2008 at 4:27 pm.

80 characters is an important limit for many reasons. Actually, I stick to 72 for most everything, including all coding in any language and in email (2 chars for each >-reply).

* Many debuggers add 8 chars with line numbers
* Some printers expect 80 chars not exceeded
* Formatting tools (lint, perltidy, etc) will generate warnings)
* Most programmers you’ll share code with will have their textwidth set to 72 or 80. When they see your code extending to 120 chars they’ll yell at you.
* ESR says so

There are actually some more reasons that I can’t name off the top of my head, but the most important factor beyond these historic limits is *vertical code density*. Most lines will be much shorter than 80. So if you keep all other lines within that (short), you will have better uniformity and compactness. I.e., the greater the line-length variety, the lower the density. Then with a good wide, high-res monitor you’ll be staring at four terminals worth of code at a time. 500 lines on one of my screens. Multiply that by nine virtual desktops (and add a second monitor), and you’re looking at a lot of code!

Aaron Toponce on May 8, 2009 at 3:07 pm.

There isn’t a hard fast rule that can be applied to all scenarios. The fact
of the matter is, you code the way you code; you write the way you write.
If you prefer 80, then great. If you prefer 120, great. If you prefer
unlimited, great. In terms of yourself, do what you want. In terms of
working with others, it’s probably best to communicate a standard among
everyone, and stick with it. In terms of dealing with others online, it’s
probably “best practice” to keep email wrapping at 72 characters, and code
at 80, just like you should bottom-post when replying to email threads, and
compose your email in plain text, not HTML. Netiquette is rarely taught,
and hardly understood.

Bats on September 24, 2010 at 1:46 am.

The 80 character limit is derived way back when they began punch cards ` 1890′s. Based on the size of the current dollar bill, you could only get 80 characters across. Like most things it is a carry over that serves no further purpose, but carries on ” just because this is the way it has always been done. This was done right up to the 1970′s, by IBM.
Bats….

Vance on May 30, 2013 at 5:21 pm.

I respect the arguments made here for 80 characters, and the overwhelming support for it is difficult to ignore. But I don’t relate with these arguments, and find the imposition of such a limit very frustrating.

From what I’ve seen, 80-char limits makes code difficult to read. It forces indecipherable variable names, and makes commenting difficult. I typically choose to lengthen my variable names a little for the sake of readability, and I prefer commenting to the right of each line, because it is the most direct and unobstructive place to put them (code at left, comments at right generally keeps them separated). Much of the code I write is examples to teach others, so ease-to-read code and explanations is a priority.

Re: the argument for vertical density, I prefer the opposite — the use of whitespace to visually separate code. Again, for readability. I think good code should be human-readable, which in the end translates to faster development time for the person inheriting it.

Jim Pivarski on August 25, 2013 at 7:01 am.

@Bob K and @Vance: I, too, find the short-line coding style difficult to read. Not everybody likes it.

For my own code, I completely disregard the length of the line. If a logical unit of nested functions wraps around my Emacs window three or four times, so be it. Despite much of what has been said above, this makes it *easier* to compare code side-by-side because the code does not have a characteristic width. 80-character code is completely indecipherable when the window is 79 characters wide or fewer— all those ragged bits of just-barely-wrapped-around lines interfere with the logical blocks. When the lengths of lines are arbitrary, they’ll rarely interact badly with a given window width (by a kind of thermodynamic average).

Introducing a fixed width only sets a characteristic scale at which everything becomes illegible all at once. In a scale-free distribution, you have more freedom to resize the window with impunity.

Leave a Reply