I wrote this on firstname.lastname@example.org today in a thread which was discussing short variable names:
My own take on variable names is that naming is one of the hardest problems in software development, and that the length of a variable name should reflect the length of the scope in which it is visible. A single letter variable name is fine in a small loop, for example. A larger scope would call for a correspondingly larger variable name.
The rationale for this is that our short-term memory can store only a small amount of information; 7 ± 2 items according to Miller, but more recently thought to be 3 or 4 "chunks". When reading or writing code, additional text such as unnecessary comments, excessive punctuation and even long names can obscure the meaning of the code making it harder to reason about. If a common variable in a small scope can be given a short name, that variable and its purpose can be stored in our short-term memory for the duration of our concentration on that scope. For larger scopes, where there are more names, this would overflow our short-term memory requiring us to go back and check what the short name actually referred to, negating the benefit of having less cluttered code.
Naturally, this is also the reason why the name must be descriptive rather than merely long, and certainly shouldn't be misleading.
And as with other names, a single letter variable name should reflect its purpose as much as possible, to further aid our understanding; $q for a queue, $c for a customer, $n for a count and so forth. The problems start to occur when we have a customer and a context, for example, and at that point having a variable named $c is more of a hindrance than a help. That's when you would want $cust and $cxt, or $customer and $context depending on the size of their scopes.