Studies on optimal code width? [closed]

Have mercy on the programmers who have to maintain your software later and stick to a limit of 80 characters.

Reasons to prefer 80:

• Readable with a larger font on laptops

• Leaves space for putting two versions side by side for comparison

• Leaves space for navigation views in the IDE

• Prints without arbitrarily breaking lines (also applies to email, web pages, ...)

• Limits the complexity in one line

• Limits indentation which in turn limits complexity of methods / functions

Yes, it should be part of the coding standard.

I don't have studies, but I will relate my experience.

I find that horizontal scrolling is tedious when dealing with text. I look at the environment that the code will be used in, and set width standards based on that context.

For example, when I worked in Emacs on XWindows, it worked well to have 2 Emacs windows side-by-side at all times. That limited them to 80 characters, so that was my max line length.

At one point I worked in Visual Studio on a 1920x1200 screen. I'd keep it maximized, with all tool windows docked down one side. There was enough space left for two editor windows side-by-side at around 100 characters.

I also find that the longest lines come from method calls with long parameter lists. This is sometimes a code smell: perhaps the method should be refactored.

If you & your co-programmers have high-resolution screens and sharp eyesight, by all means use a small font and long lines. Conversely, you may need short lines.

I normally use 120-150 unless the company describes otherwise. However it depends also on the kind of code:

• I (almost) never use multiple statements on one line
• I only use long lines (>12) only if lines that look similar can be aligned and not broken.
• I always use enough spaces/parenthesis etc
• I prefer longer variables names above shorter names

Until a few years ago I limited to 100 but now widescreens are normally used and high resolution monitors 120 can be even seen on laptops (which I barely use).

Comparing a screen to a book is not really good because a book has more vertical space and a screen has more horizontal space. I always try to keep a function max. one visible screen long.

Here is a study for you:

I teach programming for more than 30 years, and during this time I accumulated 1823 source codes in C with various routines, from random small games to neural networks, compilers, educational softwares, automatically generated lex/yacc source codes, etc.

Following the Pareto Principle, 80% of those programs have lines smaller than 159 columns. So, to cut the lower 20% and the upper 20%, we have:

• 1823 source codes
• 80% of them smaller than 159 columns
• 80% of them bigger than 64 columns

Now that is a range that gives you freedom. You don't want to limit your code to 80 columns just for the sake of it, because sometimes you will need nested loops, functions, or some indentation that will be easy to understand in a bigger line, and if you forcibly distort your logic to fit an arbitrary column width, you are not using the best logic.

Sometimes, on the other hand, the size of a line is an indicator that your logic could be better, and your line could be smaller; specially if you are not in a nested part of the code and you already crossed the limit of, say, 160 columns.

Based on my own experience and readability, I recommend you write your code aiming for 80 columns, but allowing until 120 columns of margin, and never crossing the 160 columns limit.

Also, we should consider the older experience of reading that exists: books. Books are typographically created to easy the reader's eye movement, and the best sized column according to professionals in the area is ideally around 60 characters per line, not less than 40, not more than 90.

Since coding is not exactly reading a book we can go for the upper limit, and we should stay between 80 and 90 characters per line.

Unless you are programming low level code that will run in specific screen sizes and old monitors, than I would recommend you follow gopher standard, which is 67 characters per line.

Curiosity:

• the biggest line in the 1823 source codes is a quine of 1020 columns in a single line
• the biggest line of code that is not a single line is a text adventure game with 883 lines. Of course this is good practice, because if you don't limit the break of a line, the text will be better displayed in your screen, breaking in the column you actually have as size.
• the smallest lines of code (non zero) are 14 characters long.
• the command I used to check the file sizes is: find . -type f -name "*.c" -exec wc -L {} \; | sort -n | less -N

Disregarding hardware restrictions, and any differences in how we read code versus natural language, I see three primary reasons to limit lines to around 80 characters.

1. Human eyeballs are round, not really narrow and wide, and most of their resolution is in the middle. When reading for hours at a time it is a lot more comfortable to sweep the eyes in short arcs, using one scroll bar as needed. I don't know of a formal study specific to the legibility of code, but from my own observations, with the monitor 2 feet away, with text sized at a 10pt monospaced font, 100 characters takes up about 1/3 of my horizontal field of vision, or around 60 degrees (outside of the 30 degrees or so where all our eyes' resolution is at).
2. Most people use a large monitor at work so that they can see multiple things without clicking back and forth, not so that they can see one thing really big.
3. Shorter lines contain less complexity, which hopefully forces a developer to break up make their code into more digestible units.

Maybe the 80 characters is also a good point to avoid these bad getter chains:

object.getFoo().getBar().getFooBar().get ...

if you limit it to 80 characters, maybe someone would localize these variables and do null check etc, but maybe most programmers would let them wrap in the next row. i don't know

Beside that, 80 characters are great as starblue mentioned. This should defenitely goes into the coding standards.

The right margin option is intended to show you the width of the page if you're going to print the code, and has previous posted said it was set to 80 because that's what the line length historically was before GUI all the way back to punch cards.

I've seen a recommendation on some blog recently (can't remember what blog) to increase you IDE font size in order to improve code quality, the logic behind it is that if less code fits on screen you'll write shorter lines and shouter functions.

In my opinion shorter lines make reading the code and debugging it easier, so I try to keep the lines short, if you have to set a limit to make yourself write better code then choose what works for you - also if you are more productive with longer lines feel free to increase the page size and code only on a wide screens.

I distinctly remember reading somewhere (I think it was in Agile Documentation) that for optimal readability a document's width should be about two alphabets, or 60-70 characters. I think the old terminals' line width came in part from that old typographical rule.

As some people have pointed out in other answers the reason for the 80 character limit is partly historical (punch cards, small screens, printers etc) and partly biological (to track what line you are in it's generally good to be able to see the entire line without needing to turn the head).

That said, please remember that we are still humans and we build tools to solve our own limitations. I propose you ignore the entire debate about character limitation and just write stuff that makes sense regardless of their length, and use an IDE or text editor that can help you keep track of the lines properly. Using the same argument for indentation in the tabs vs spaces debate, as well as the how wide should the indentations be I propose you use an indentation marker (most commonly the tab) and just have people configure their own IDE or text editors to display them as they find most comfortable to them.

Sticking with a fixed number of characters per line will always make things worse for everyone but the targeted audience. That said, if you will never share the code, ever; then there's really no reason to even have this discussion to begin with. Should you want to share the code, you should probably let people decide what they want on their own instead of forcing yours (or someone elses) ideals on them.

To the best of my knowledge the 80 character is used as a coding standard to maintain compatibility with command line editors (default terminal width is typically 80 characters). With modern IDEs and large screen resolutions 80 characters is probably not "optimal", but for many developers maintaining readability in the terminal is essential. For that reason it is not likely that 80 character width will be replaced as the de facto standard for code width anytime soon. And to answer your final question, yes, code width as well as any other characteristic which will affect your code's readability should be addressed in your coding standards.