Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
2  
@BillyONeal With big screens, 120 :) –  BЈовић Jan 18 '13 at 7:43
3  
I think I need at least 130 –  9dan Jan 18 '13 at 7:45
8  
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
5  
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
4  
@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
show 8 more comments

closed as not constructive by gnat, Walter, BЈовић, GlenH7, Glenn Nelson Jan 18 '13 at 13:13

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

5 Answers

up vote 29 down vote accepted

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.

share|improve this answer
3  
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
add comment

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.

share|improve this answer
2  
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 9: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
add comment

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

share|improve this answer
    
+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
add comment

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.

share|improve this answer
2  
Does 80 characters really improve readability? What screen can't easily do 120 these days? –  Billy ONeal Jan 18 '13 at 7:20
6  
@BillyONeal it's easier to scan over 80 width than over 120 width –  ratchet freak Jan 18 '13 at 7:33
2  
the news paper break into columns, and you can have more information from ux ux.stackexchange.com/questions/3618/… –  neo Jan 18 '13 at 9:21
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. –  TheTerribleSwiftTomato Jan 18 '13 at 9:43
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
show 5 more comments

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.

share|improve this answer
2  
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 programmers.stackexchange.com/questions/148677/…. 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 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 8:01
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.