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.

  • 4
    @BillyONeal With big screens, 120 :) Jan 18, 2013 at 7:43
  • 4
    I think I need at least 130
    – 9dan
    Jan 18, 2013 at 7:45
  • 8
    I prefer 80, because I can then easily open 2 files side by side on my notebook. Jan 18, 2013 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. Jan 18, 2013 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, 2013 at 13:04

5 Answers 5


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.

  • 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, 2013 at 12:26

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
    +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, 2013 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, 2013 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, 2013 at 12:50

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.

  • 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, 2013 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.) Jan 18, 2013 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, 2013 at 12:33

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.

  • 2
    Does 80 characters really improve readability? What screen can't easily do 120 these days? Jan 18, 2013 at 7:20
  • 8
    @BillyONeal it's easier to scan over 80 width than over 120 width Jan 18, 2013 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, 2013 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.
    – mikołak
    Jan 18, 2013 at 9:43
  • 1
    @BillyONeal: most screens can do 120, but hardly any can do 240. Or do you never compare diffs? Jan 18, 2013 at 11:52

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!


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.

  • 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, 2013 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, 2013 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, 2013 at 8:01

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