On Tue, Sep 13, 2011 at 11:34:34PM -0400, Uri Guttman wrote: > here is another good reason to stay aways from single letter var > names. they are hard to search for as other vars which start with those > letters will also be found.
This may be the worst argument I have ever heard against using single letter variable names. Please don't let your code be held hostage to the tools you are using, especially if there are better tools available. 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, excess 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 fill 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 if a hindrance than a help. That's when you would want $cust and $cxt, or $customer and $context depending on the size of their scope. -- Paul Johnson - p...@pjcj.net http://www.pjcj.net -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/