Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re^2: Perl Style: Is initializing variables considered taboo?

by ait (Friar)
on Aug 21, 2010 at 15:41 UTC ( #856467=note: print w/ replies, xml ) Need Help??


in reply to Re: Perl Style: Is initializing variables considered taboo?
in thread Perl Style: Is initializing variables considered taboo?

Of course I use strictures in all my code! Why else would I be asking about variable initialization if I did not predeclare them?
The question was more on style (hence "Perl Style") and the fact that the pod for my in perlfunc does not specify if it actually initializes the variable to any specific value.
Nevertheless, after your response I discovered that perlsyn pod does under "Declarations" and quite extensively explains the initialization details. It seems that in a few cases it is wise to initialize, but not to undef, because as you say, it is just plain wasteful. Though IMHO I still think it just looks neater in the code, but shall refrain from doing so to undef in the future.
I have a faint memory that I picked up the practice many years ago from the Camel book (or PBP), and I think it states somewhere that it is good practice to always initialize variables, but I could be wrong... or maybe it's just an old habit from my background in C.


Comment on Re^2: Perl Style: Is initializing variables considered taboo?
Re^3: Perl Style: Is initializing variables considered taboo?
by LanX (Canon) on Aug 21, 2010 at 15:49 UTC
    there are cases where assigning undef makes sense but generally it's a waste of time (which is not Perl style ;)

    Applications are especially when passing "positional" lists or assigning to lists, with "gaps".

    i.e.

    ($a,undef,$b)=@array; # ignore second parameter
    or
    function($a,undef,$b) {..} # treat second parameter as not suppl +ied

    The latter is especially necessary if you are checking arguments within the sub for definedness and changing to default values.

    UPDATE: An extension of this case is a hash or array element which exists but is not defined!

    > Of course I use strictures in all my code!

    it's more about use warnings to be warned about undefined variables.

    UPDATE:

    and please be careful not to return undef to "explicitly" return false.

    Subs return lists, so what you are actually doing is returning a one-element list instead of an empty one. I.e. @array=func();

    Using a blank return is the same like return (); and won't byte you in list context but in scalar context the variable will be undef anyway.

    Cheers Rolf

      If I need to discard a value from an array or from a list of return values, I usually index the list, rather than assign values into undef.
      ($a, $b)= @array[1,3]; my ($minutes, $hours) = (localtime())[2,3]
      Though the localtime example is artificial, I rarely do anything with list-context localtime(), anymore, other than feed it into Posix::strftime().

      --
      TTTATCGGTCGTTATATAGATGTTTGCA

      and please be careful not to return undef to "explicitly" return false.
      Many people use return undef to indicate false in the execution of a sub, but it's likely I'm really not getting what you mean by "explicitly":
      perl -e 'foreach (@INC){print "$_\n" unless $_ eq q{.}}' | xargs grep +-R "return undef" | wc -l<br> 1752
      Subs return lists, so what you are actually doing is returning a one-element list instead of an empty one. I.e. @array=func(); Using a blank return is the same like return (); and won't byte you in list context but in scalar context the variable will be undef anyway.
      I have found it wise to always return an explicit value, to avoid a potential bite or 'feature' of the "last expression", and have till now, used undef to indicate falseness and failure, and a defined value or "1", to indicate trueness/success.

      As you point out, it is often overlooked that Perl returns lists and as a result most of the time subs are evaluated in scalar context; in OO code it's customary to return a single ref to an object or undef on failure. So what exactly do you mean by not returning undef to "explicitly" return false.

        In scalar context, return; evaluates to undef. In list context, it evaluates to the empty list. In both contexts, it evaluates to something which evaluates to false in boolean context.

        In list context, return undef; evaluates to a single-element list which evaluates to true in boolean context.

        > So what exactly do you mean by not returning undef to "explicitly" return false.

        maybe a little example will make it clearer

        DB<1> sub tst {return undef} DB<2> if ($a=tst()) {print "TRUE"} else {print "FALSE" } FALSE DB<3> if (@a=tst()) {print "TRUE"} else {print "FALSE" } TRUE DB<4> sub tst { return (); } DB<5> if ($a=tst()) {print "TRUE"} else {print "FALSE" } FALSE DB<6> if (@a=tst()) {print "TRUE"} else {print "FALSE" } FALSE

        line 4 is of course redundant, return; and  return (); do exactly the same thing.

        > I have found it wise to always return an explicit value,

        OK, if you wanna code more "explicitly", you should better define constants for TRUE, FALSE and FAILED.

        DB<9> use constant FAILED => (); DB<10> use constant FALSE => !1; DB<11> use constant TRUE => 1; DB<12> sub t_FALSE { return FALSE; } DB<13> sub t_TRUE { return TRUE; } DB<14> sub t_FAILED { return FAILED; } DB<15> if (@a=t_FAILED) {print "TRUE"} else {print "FALSE" } FALSE DB<16> if (@a=t_FALSE) {print "TRUE"} else {print "FALSE" } TRUE DB<17> if ($a=t_FALSE) {print "TRUE"} else {print "FALSE" } FALSE DB<18> if ($a=t_FAILED) {print "TRUE"} else {print "FALSE" } FALSE

        If you wonder about my definition of FALSE, see Truth and Falsehood in perlsyn:

        Negation of a true value by "!" or "not" returns a special fals +e value. When evaluated as a string it is treated as '', but as a number +, it is treated as 0.

        UPDATE:

        please note: FALSE is defined!

        DB<27> p !defined (FAILED) 1 DB<28> p defined (FALSE) 1

        i.e. FALSE acts like a defined value like in most other languages.

        UPDATE:

        On second thought FAILED should better be named EMPTY or NOTHING. Failure is just an interpretation of returning nothing.

        Cheers Rolf

Re^3: Perl Style: Is initializing variables considered taboo?
by BrowserUk (Pope) on Aug 21, 2010 at 16:53 UTC
    Of course I use strictures in all my code!

    I did say "if". Not everybody uses strict; and I don't know you from the next guy; so there is no "of course" about it.

    Why else would I be asking about variable initialization if I did not predeclare them?
    Because initialising/reinitialising your variable to undef becomes very important if you don't use my, because globals have this habit of retaining their values from previous iterations of loops, and previous calls to subroutines.

    As for style, that is in the eye of the beholder. I find much perlstyle a total anathema; often supported by nothing more than justifictions.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
Re^3: Perl Style: Is initializing variables considered taboo?
by Marshall (Prior) on Aug 22, 2010 at 01:43 UTC
    I've read through the posts and there is certainly a lot of verbage here!

    As long as you aren't using the very ancient C style where all the variables had to be declared at the beginning of the sub instead of when they are first used or close to where they are first used as in modern C, I don't see any problem at all.

    Often I see my @x=(); vs just my @x;, but I don't see any big point to get really riled up about! I seldom see a statement with a scalar like my $x=undef; vs my $x; because something happens with $x in the next line or two. An array or hash declaration happens more often closer to the beginning of the code and can have a wider distance between declaration and use.

    Of the universe of style issues, this issue probably shouldn't be at the "top of your hit parade".

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://856467]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (11)
As of 2014-07-29 12:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (217 votes), past polls