in reply to The Marcel Perl Questionnaire

My favorite special variable is good old $_.

Yesterday I realized that it is Perlish to assign variables to $_ explicitly. For instance, I can say: 

$_ = "LamourEstBleu";
if (/Bleu/){
    print;
}

[download]

At one time I would have considered the above snippet to be obfuscated, because to a novice Perl programmer it is saying "Print something, but I am not going to tell you what to print."

Now I see that this Perlish way of using $_ can make code clearer, by not repeating the variable name over and over again.

If a variable is a proper name, then $_ is like the word "it". Most of us when speaking French/English whatever do not refer to a subject explicitly every time, but use implicit references like "it" as well, where the meaning of "it" is apparent from the context.

Similarly, the meaning of $_, which is like the word "it" in spoken language, is apparent from context. As we deepen our own Perlishness I believe that many of us will use $_ more and more often. I know I will!

Replies are listed 'Best First'.
(ichimunki) re: assigning to $_
by ichimunki (Priest) on Feb 24, 2001 at 19:46 UTC
    Why? Again. Why?

    That variable has so many side-effects from normal processing that assigning to it is likely to bite you rather quickly.

    You can't use the impersonal pronouns (he/she/it in english) without first either using the actual noun, or unless the actual is strongly implied.

    Witness:
    "It runs." -- um, what does?
    "The dog has spots. It runs." -- now we know what runs.
    "The dog has spots. The cat has stripes. It runs." -- the dog or the cat?

    I don't know what others think, but I'd say you aren't solving a real problem by not using an actual variable name, but you might be causing some.

    Good variable names give clues about what is in that data structure, and how it would normally be used. $_ gives no indication anything.
[reply]
Re (tilly) 2: The Marcel Perl Questionnaire
by tilly (Archbishop) on Feb 24, 2001 at 22:43 UTC
    That is a bad habit, which if you are just starting you would be advised to break right now.

    Please see my comments in the thread starting at $_ haters anonymou for details of why.

    For the record, I am still not confident that I know all places where $_ will be used unexpectedly to me. You should not stomp over it thoughtlessly. Instead leave $_ alone before you have to ask how your map statement wound up eating up the array...

[reply]

      As far as $_, I think that the problem of the many uses can be overcome by simply doing 

      {
    local $_;
    # stuff...
}

      [download]
      .

      I haven't seen this do anything too weird, and it provides a good way to overwrite $_ temporarily. It sort of reminds me of elisp's (save-excursion ...) Anyway, here's my answers to the questionnaire -- favorites are first.
      (Least) Favorite Perl Instructionlocal; resetSee above. Why reset? Too dangerous, especially when you've got tons of single-char vars.
      (Least) Favorite Looping Mechanism{}; forNaked blocks give you more flexibility. for just seems useless to me.
      (Least) Favorite ModuleData::Dumper;Dump those objects! No least favorite -- I sort of like them all.
      (Least) Favorite Special Var$_; $]$_ is so useful. $] is not.
      Favorite Var TypetypeglobVery obfuscatable.
      (Least) Favorite Command Line Switch-e; -U-e allows me to do one-liners. -U does unsafe things.
      Favorite Pragmause strict; no strict "refs";Good for bugcatching, except when I want to use symbolic references.
      Favorite Regexp {Modifier,Metachar}i; \QYes to i! Too much work to manually decapitalize all the time. \Q useful for when arbitrary data comes in which you need to match.
      Favorite Descriptive Var Name%zNot very descriptive, but I like it nonetheless.
      Favorite HERE doc delimiterprint;Or some other command...
      Favorite FilehandleFOOShould be obvious why...

[reply]
[d/l]
        The majority of the problems can indeed be solved that way. (Though good luck if you forget a local anywhere.) But there are more subtle maintainability issues with implicitly passing data in global variables. Code that is explicit about where data that is being acted on came from is better than code which hides that information elsewhere.

        This is also why I dislike local. Oh, I know when to use it and I do use it correctly. But I prefer not needing it. Perl has too many scoping mechanisms whose interactions are too baroque. Rather few people really understand it, and when people are working with interfaces they don't understand they get confused and make mistakes. (Often without knowing that they made mistakes.) As the documentation says, local is probably not what you wanted to use, my is generally more appropriate...

[reply]

In Section Meditations