The problem is worsened when programmers invent lousy names for things as we often do. The bloated source that results can look more like bad prose than an algorithm. [Consider that the same person who wrote the unhelpful comments --if they did-- probably picked the names too.]

This can be ameliorated, as others here have pointed out, by using short names for short-lived, locally-scoped variables. Readability can be further improved through judicious use of “negative space,” that is whitespace and anonymous functions and/or objects. In other words, pitch the names altogether. As example, FP-style encourages this.

A style guideline that helps is to require devs to write short and simple classes and functions. This embodiment of the “Single Responsibility Principle” (SRP) produces decent names in my experience. Code review enforcement will help too.

When it comes to processing large amounts of sql queries or data in general, I’ve found short at the most 3 char length variables work well. And watching memory stats on my hosting server when processing pages, reusing variable names helps to keep memory overhead low. For e.g. I might use $s to do a sql query, and then use $r on the fetch array loop, then if other parts in the same page/script need to make fetch array and sql query calls, i’ll use $s and $r again.

On a slightly different note. I’ve noticed by watching cpu load times and memory overhead on a local machine when referencing array especially, if you use for e.g. $r[name] as a reference in the array to work with that data, is slower than using $r[4] to reference the same data, obviously 4 would be the 4th position where name coincides within the array.

I originally started using short var names to save document space and to keep file size down, just as removing all white space does, and studying the speed difference, the change can be quite dramatic, for not only speed, but file size. Just think, if you have your code tabulated, and spaced out, which is great for readability, but not for overall performance.

@Eric: Yeah, sure we should distinguish between cases and I’d buy the general rule you suggested right away. But then again, if I’m trying to advocate a change in style then I find it easier to advocate a complete change and to be more strict, even about short-living variables. We know that it won’t be respected 100% of the time anyways.

I’m also a big fan of re-factoring big methods into smaller ones although not only for code style and readability nor for maintainability or re-usability, but for testability reasons. Just so much easier to write some quick JUnit tests for separate methods.

Why? Because that object won’t live for more than 2 lines.

The general rule should be like this:

Short-living / small scope:
3- identifier is enough, if the code is written well enough to be self-explanatory. Otherwise, add comments.

Long-living field / huge method:
Needs a full qualified name. However, writing methods with more than 30 lines is a vast crime by itself. Rather than introducing long variables, I tend to refactor these beasts into smaller, well defined methods with meaninful names.

Good functional-oriented and reusable design is usually preferably well documented, but long and quirky imperative code. Even in languages like Java.