Beefy Boxes and Bandwidth Generously Provided by pair Networks
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)

  • camelHumpVars are more difficult for non native english speakers to read properly. As the development base of Perl is truely international (unlike many other langauges which are strongly US/English based, such as Java) making life easy for non english speakers is generally considered to be a desireable thing. camel_hump_vars is much easier for a non native english speaker to parse correctly.
  • camelHumpVars are more difficult to read at 4 o'clock in the morning for everybody. When you can barely keep your eyes open, and what eyes you can see are a mess of broken blood vessels (ie bloodshot) from the hours of dev, every little bit that makes things clearer is well appreciated.
  • camlHumpVars are ugly. This is just my opinion, but reviewing large quantitiy of code you will find very little written in this style and I do not believe that the above two reasons can account for this apparent consistancy. Also consider they dont scale well when the identifier contains multiple words. Ie theFunkyVarThatGetsUsedByPrintToPutSeperatorsInItsOutput is a lot harder to grok than the_funky_var_that_gets_used_by_print_to_put_seperators_in_its_output.
  • The rules for camelHumpVars dont generalize, ie its common to use all caps for constants or "near-constants", and special vars. So then you have camelHumpVars and CONSTANT_VALUES which are different rules. Whereas camel_hump_vars and CAMEL_HUMP_VARS are nicely consistant and apply everywhere.
  • larry_prefers_this_style. :-)

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
in thread Help with the concept of closures. by DigitalKitty

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others examining the Monastery: (4)
As of 2024-03-28 15:38 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found