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.

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

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.

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.

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.