laziness, impatience, and hubris | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Hi digitalkitty. Other respondants have provided a wealth of information about closures, but I'd like to point out what I consider to be a few style nits in your code. my $item = shift(); To me is a potential error. If the shift is intended to operate on its default var (either @_ or @ARGV depending on where the shift is called from) then dont bother with the parens. When I see the empty parens in a situation like that I think "hmm, there should be something in there, did somebody forget something?" whereas my $item = shift; says to me "they are using the default var, no worries". If you feel the parens are necessary then put the object that shift is working on in as well. (And even then the parens are superfluous. my $item = shift @_; is IMO better than my $item=shift(@_);). Second is the use of camelHumpIdentifiers. Generally speaking these are frowned upon in the perl scene. People that do use them tend to come from other languages where this style is prevalent and bring it along as part of the baggage from the other. There are several reasons why identifiers such as these are frowned upon (in no particular order)
A last nit is the use of ampersand in stuff like &$itemInBasket( "pair of shoes" ); Most perl programmers believe that this is ugly, and to some degree confusing. (I realize there is a small amount of debate about this, but there isnt much.) The reason is that the ampersand has special meaning in certain situations. For instance if you saw a function call like this &function; and then blihely added parens to it, then you would dramatically change the meaning of the statement. My rule for the ampersand notation is that they should only be used when they are absolutely required. This means that when they are present it is immediately notable and says to the maintenance programmer 'something special is going on here, be careful'. Whereas when you use them as general rule there is no such mental danger flag associated with them. The only time they are required is when you taking a reference to a named subroutine -- actually that isnt strictly true, one can use the *subname{CODE} notation to the same effect -- and when you are using the magical form &subname; or the really magical goto &subname; or when you have named a sub the same as a keyword (which is a bad idea generally anyway IMO) and need to disambiguate -- which again isnt strictly true, one can avoid them in that case by using a full qualified subroutine name. My rule is that $obj->attr; is ok for attributes, $obj->method() is preferable for methods, $coderef->() is preferable (compared to &$coderef();) for calling an anonymous sub, namedsub(); is preferably for calling a argumentless named subroutine, and namedsub "with arguments"; is preferable (when unambiguous) to namedsub("with arguments"); And from what Ive seen here on PM in terms of code and comments and in the vast majority of code ive reviewed from CPAN and the standard distro most people agree with me. Perl code is relatively "live" and "noisy", anything that can be done to reduce the level of noise (such as eliminating blocks and parens) is probably a Good Thing, and will improve the readability and thus the maintainability of your code. Anyway, theres lots of food for thought for you in this thread. Have fun and good luck. --- demerphq <Elian> And I do take a kind of perverse pleasure in having an OO assembly language... In reply to Re: Help with the concept of closures.
by demerphq
|
|