>>>>> "PJ" == Paul Johnson <p...@pjcj.net> writes:
PJ> 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. PJ> This may be the worst argument I have ever heard against using PJ> single letter variable names. Please don't let your code be held PJ> hostage to the tools you are using, especially if there are better PJ> tools available. show me a tool that can search for single letter names cleanly and with little effort as compared to longer names. also this isn't the only reason, just one of several. PJ> My own take on variable names is that naming is one of the hardest PJ> problems in software development, and that the length of a PJ> variable name should reflect the length of the scope in which it PJ> is visible. A single letter variable name is fine in a small PJ> loop, for example. A larger scope would call for a PJ> correspondingly larger variable name. PJ> And as with other names, a single letter variable name should PJ> reflect its purpose as much as possible, to further aid our PJ> understanding; $q for a queue, $c for a customer, $n for a count PJ> and so forth. The problems start to occur when we have a customer PJ> and a context, for example, and at that point having a variable PJ> named $c is more if a hindrance than a help. That's when you PJ> would want $cust and $cxt, or $customer and $context depending on PJ> the size of their scope. and $q or $c is still a poor name even in a tight scope. it tells nothing to the reader about the content of the variable. it is just a placeholder for the author. you might as well just use $_ everywhere you can. names need to convey information about variable usage. single letter ones have very little information. uri -- Uri Guttman -- uri AT perlhunter DOT com --- http://www.perlhunter.com -- ------------ Perl Developer Recruiting and Placement Services ------------- ----- Perl Code Review, Architecture, Development, Training, Support ------- -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
