Descriptive naming vs. 80 character lines

Question

I frequently hear these two valuable programming practices: (1) lines of code should be 80 characters or less and (2) use descriptive names for variables, methods, classes, etc. I understand the reasoning for both of these words of advice, however, they seem to often be tradeoffs of each other. If I keep my code below 80 chars/line I end up using less descriptive names (esp. in Python in which each indentation counts as 4 characters) but if I use more descriptive names, I end up with lines over 80 characters.

So, my question is which of these two pieces of advice is more important to abide by if the choice must be made? I am wondering this as an independent (hobbyist) programmer, but more importantly from the perspective of a software engineer working for a larger company.

I'm still an 80 character man, though I admit it can be difficult at times. — Craige, Jan 18 '13 at 07:46
It make me sad.. sacrificing developers viewing angle for the sake of monitors and/or printers. — 9dan, Jan 18 '13 at 07:47
Randome sample: NSString* targetBundlePath = [[thisBundlePath stringByDeletingLastPathComponent] stringByAppendingPathComponent:APP_NAME];, it's 123 — 9dan, Jan 18 '13 at 07:49
Personally, I think the idea of **80 non-indentation-whitespace** characters per line is a better compromise these days. That solves a big part of your problem right there, but of course it doesn't answer your question of "which is more important". — user, Jan 18 '13 at 10:18
I prefer 80, because I can then easily open 2 files side by side on my notebook. — Honza Brabec, Jan 18 '13 at 10:49
Everyone has his preference. Someone like short lines of code even by breaking a line. But I don't always like that. Sometimes unpleasant breaking makes your code even harder to read. On another hand, too many long lines are also annoying, as you have to scroll back and forth for each line -- you may have to scroll hundreds of times before you finish reading a short program. So I think one or two long lines is not a big deal for well organized code. I think descriptive is more important in most cases. — shuangwhywhy, Jan 18 '13 at 11:27
Lines longer than 80 characters tend to get unreadable. So 80 is a good limit. Descriptive need not be too verbose. And it depends of the scope: small scope short variable names, large scope longer names. And by all means avoid variables with large scope. If you are at it use a functional language and break your code in smaller functions when it indents too deep -> very small scope == short varnames. Function names are similar but usually a bit longer because their scope is larger. — Peer Stritzinger, Jan 18 '13 at 11:47
There should be no line limit anyway. In the plain textfile and the repository the line should be just as long as it is. All you need to do is to teach your editor to present the line according to your preferences. Think of a LF as end-of-paragraph in a text processing program. — ott--, Jan 18 '13 at 12:04
@ott--: Have you seen an editor, that can actually break a long line, according to C++ syntax, and present the continuation indented one more level than the beginning? Otherwise such suggestion is useless. — Jan Hudec, Jan 18 '13 at 13:04
[Is the 80 character limit still relevant in times of widescreen monitors?](https://softwareengineering.stackexchange.com/questions/604/is-the-80-character-limit-still-relevant-in-times-of-widescreen-monitors) — gnat, May 23 '19 at 09:17

score 34 · Accepted Answer · answered Jan 18 '13 at 05:11

Keep your indents few, your names descriptive, and don't be afraid to break a line.

Keep your indents few.

Often when I find myself in a struggle between indents vs descriptive naming, I take a step back and look at my indention level. If you're indenting further than 3 or 4 levels (2 levels is automatic and unavoidable in many instances. Read: class method definition), you may want to restructure your code, abstracting functionality out to a function or method.

Your names descriptive

You should always keep your names descriptive. Descriptive names create self-documenting code. You can try to shorten the names in some instances, but readability comes first.

Don't be afraid to break a line

Shit happens. If you go over 80 characters, and you don't see anyway to reclaim any space in the line - break it. Most languages don't care about line breaks, so break the line into multiple. Don't just pick a random location. Keep things grouped logically, and indent another level when you do break the line.

It should be noted, that descriptive names is not the same as long names. Avoiding repetition of things that can be easily seen from context and a handful of _carefully_ chosen abbreviations (only for the _very_ common concepts) can go a long way towards short descriptive names. — Jan Hudec, Jan 18 '13 at 12:26

score 18 · Answer 2 · answered Jan 18 '13 at 11:17

Why Not Both?

First of all, "descriptive" and "verbose" are not the same. For example, if you're writing a fairly local loop, i is a very good variable name for the loop variable; current_iteration_index, while arguably more descriptive and definitely more verbose, is much worse and does not add any information at all, because the use of i as a loop variable is pretty much universally accepted, and there is no other meaning to i than that.

Good variable names are descriptive, in that a programmer familiar with the language's idiom and the codebase's conventions can easily guess what their role is, but they are also concise enough to keep things compact.

The 80-character limit, while originally a consequence of technical limitations of 1970's text terminals, is still valued by many today, and even though there are still technical reasons (maximum line lengths in some network protocols, most notably e-mail related), the more compelling reasons are psychological and social ones. It turns out that line lengths around the 66 character mark make for the most comfortable reading experience for natural-language prose (the font size interestingly doesn't make much of a difference, and consequently, neither does the screen or paper size); 80-character line limits are pretty close to that, but since the bulk of a typical piece of code is usually indented at least one or two levels (which means between 4 and 16 characters, depending on indentation settings), we end up with something that is pretty close to 66 (between 64 and 76 characters).

Another effect of sticking to 80-character lines is that it's a pretty good indicator of when things are too complicated. Lines that long are usually caused by one of the following:

Functions with a long list of arguments; this is not a nice thing to have, because they impede readability and can easily cause subtle bugs, e.g. when people swap argument order in a way that the compiler doesn't catch.
Complex expressions, often found in conditionals (e.g. if ((user.isLoggedIn && user.hasPermission(page.getRequiredPermission()) && !user.isBanned) || page.getRequiredPermission() == null)); this, too is usually rather hard to decipher, and the code should be rewritten into something more structured. Most likely, the expression does too much and should be factored out into a method or function.
Long literals used in function calls or expressions, e.g. print(translate(LANG_EN, LANG_ES, "This is the home page. Feel welcome to click around and see what we have."));. Move the literal into a variable or constant; it might still exceed the line length, but if you do it consistently, the reader can at least safely ignore the invisible part of the line, assuming that only the remainder of the literal follows. Or better yet, move the literals out of the code and into an external data store (file, database, whatever).
Deeply nested statements, e.g. six levels of if statements in a class method (that's 32 columns of indentation for typical settings). Again, deep nesting makes for complex and hard-to-read code, and should be avoided like the plague - put simply, deep nesting overflows the human brain's stack while reading.

All these are ultimately symptoms of things you rather wouldn't have in your code base in the long run, and enforcing 80-character limits is a nice and simple way that helps keep complexity down and readability up. (That's not to say you can't write perfectly unreadable code in 80 columns: the various obfuscated-something-code contests are a clear counter-example).

+1: Great answer except I don't agree with moving literals away from the code. When you know which literal you are looking for, you can grep for it in resources or code equally well, but when you are working with the code and need to modify the literal, having to hunt for it in separate file is quite a distraction. Also note, that all languages have some way of splitting literals to multiple lines, which is what I'd do in such case. — Jan Hudec, Jan 18 '13 at 12:45
Of course the sentence used as example of long literal has no place living in source code. Things like this go in the page templates. But for things like error messages I prefer keeping them with the code that emits them. — Jan Hudec, Jan 18 '13 at 12:48
@JanHudec: Sure, moving the literals to a data file doesn't always make sense. I'm talking about overly long literals though, and with those, I have rarely seen an occasion where defining them elsewhere would have made the code any worse: the length of the text is disruptive to reading, while the meaning of it could easily be condensed into a constant or variable name, which you then define elsewhere. Error messages are a judgement call, I guess. — tdammers, Jan 18 '13 at 12:50

score 16 · Answer 3 · answered Jan 18 '13 at 05:02

16

Descriptive naming is by FAR more important. In most interfaces we can scroll to see longer lines. In no instance can the system help you translate poorly named variables and functions.

answered Jan 18 '13 at 05:02

Matt S

3,273
15
25

3

This. Stop breaking lines on X characters, let the IDE handle that. Else you bother all other users (including future you!) who's screens/IDE's can handle 2*X characters with code that doesn't fit on one page anymore. – Konerak Jan 18 '13 at 09:10
4

The question was implicitly about **long** names though. And I don’t agree that names should be long – most of the time they should be *short*. Descriptive, long names can make code harder to read than slightly less descriptive but shorter names! (Overly long lines are generally hard to read.) – Konrad Rudolph Jan 18 '13 at 12:11
4

I disagree. If I can't see the code at once, it's hard to read, no matter how descriptive the names are. – Jan Hudec Jan 18 '13 at 12:33

score 4 · Answer 4 · edited Jan 18 '13 at 05:15

4

80 characters per line is not difficult to meet even naming are long because there are many ways to break a single line of long code into multiple short code, e.g., I can break a condition statement in C into multiple lines to fit in less than 40 characters,

if ( a == b || c == d  || d == e
    || c == e || c == a || c == k
    || c == l)

you can also split a line of functions call into multiple lines too.

Therefore, both rules of descriptive naming and 80 character lines have no contradiction, they can coexist to improve readability.

edited Jan 18 '13 at 05:15

Manoj R

4,076
22
30

answered Jan 18 '13 at 05:09

neo

226
2
7

2

Does 80 characters really improve readability? What screen can't easily do 120 these days? – Billy ONeal Jan 18 '13 at 07:20
8

@BillyONeal it's easier to scan over 80 width than over 120 width – ratchet freak Jan 18 '13 at 07:33
But isn't breaking a single condition like this reducing readability? (Or any instruction for that matter.) – Silver Quettier Jan 18 '13 at 08:51
2

the news paper break into columns, and you can have more information from ux http://ux.stackexchange.com/questions/3618/ideal-column-width-for-paragraphs-online – neo Jan 18 '13 at 09:21
breaking a complex condition into lines improve readability. of course my sample is too simple but the question is about 80 characters line, not when should we break codes into lines. – neo Jan 18 '13 at 09:27
1

Breaking a logic condition up improves readability when the line breaks correspond to the condition's structure, but not necessarily if they only correspond to some arbitrary limit. – mikołak Jan 18 '13 at 09:43
@BillyONeal: I have 19" LCD at 1280x1024, with IDE toolbars eating almost half of the width I'm left with roughly 80 chars. However I fully agree that full-HD and 100 chars per line is much more convenient nowadays. – Kromster Jan 18 '13 at 10:00
1

@BillyONeal: most screens can do 120, but hardly any can do 240. Or do you never compare diffs? – Hubert Kario Jan 18 '13 at 11:52
If you write program in a group or open source, you need to consider other's preference too. – neo Jan 18 '13 at 12:10
Most screens may have more than 80 char width. But, when you split windows inside your text editor, 80 char lines won't wrap over two lines, which is good. – dheerosaur Jan 20 '13 at 11:46

score 1 · Answer 5 · edited Apr 12 '17 at 07:31

1

80 limit is something that should have been increased long time ago. Note that this limit is used since age when length of every identifier was limited to 8 characters and only one font on the screen/printer. No possibility to change font size.

God, we have different screen and printing technology now. We have very different programming languages. There's no reason to use 80 characters anymore. Increase it to 120 chars at least.

Even then it shouldn't be a hard limit. You go one character over the line? Well, nothing happens!

Edit:

Detailed answers about the history of 80-char limit

Characters Per Line on Wikipedia

A study at Wichita State University found that CPL had only small effects on readability, including factors of speed and comprehension. When asked for preferences, however, 60% of respondents indicated a preference for either the shortest (35 CPL) or longest (95 CPL) lines used in the study. At the same time, 100% of respondents selected either one of these quantities as being the least desirable.

edited Apr 12 '17 at 07:31

Community

1

answered Jan 18 '13 at 13:03

Sulthan

1,459
9
10

4

No, the limit definitely shouldn't be increased. Because it has totally nothing to do with screen and printing technology, only with the fact that 80 characters per line is about maximum human eyes can comfortably scan (66 characters is considered optimal line width, less in multi-column print). Which by the way means that most books have quite a bit fewer than 80 columns for code samples. – Jan Hudec Jan 18 '13 at 13:16
3

@JanHudec It has everything to with the screen/printing technology. Refer to http://programmers.stackexchange.com/questions/148677/why-is-80-characters-the-standard-limit-for-code-width. The decision to go with 80 characters is purely historic, not based on studies. Could you please add links to studies to confirm your opinion? – Sulthan Jan 18 '13 at 15:01
Another question already got [this UX link](http://ux.stackexchange.com/questions/3618/ideal-column-width-for-paragraphs-online) in it's comments; further references there. While the number 80 itself is historic coincidence, it is roughly derived from number of strikes per line on typewriters, which was roughly derived from common width of single-column print and average of 66 letters was long established tradition for that. – Jan Hudec Jan 21 '13 at 08:01

Descriptive naming vs. 80 character lines

5 Answers5

Keep your indents few.

Your names descriptive

Don't be afraid to break a line