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