http://www.perlmonks.org?node_id=479443


in reply to Yet another array problem

I generally try to avoid operating on @_ and $_ wherever possible, to avoid confusion and pitfalls like what you may be experiencing. Here's some code I whipped up that I think does the operation you desire but in a slightly different way. 
#!/usr/bin/perl
use strict;
use warnings;

my $var = '';
my @array = ();

foreach my $line (<DATA>) {

    chomp $line;
    @array = split(/\t/,$line);
    $var = $array[0]; #<- not necessary, but wanted to mimic OP's code
    print "$var\n";

}

exit;

__DATA__
1    4    8    9
23    432    23    21
98    87    4    32

[download]
Does that help any?

Replies are listed 'Best First'.
Re^2: Yet another array problem
by blazar (Canon) on Jul 29, 2005 at 15:49 UTC
    I generally try to avoid operating on @_ and $_ wherever possible, to avoid confusion and pitfalls like what you may be experiencing.
    @_ and $_ are idiomatic of Perl. The former is much a Perl5 thing, but the latter will also be there in Perl6, more powerful than ever! Their use can be confusing only to non-perl programmers trying to hack at Perl. Also, while you can avoid "operating" on $_ (but only if you want to make your life more complicated than necessary!), @_ is the only means to pass parameters to subs, so you can't avoid to "operate" on it. Or do you prefer to clobber your main namespace of global variables?
    Here's some code I whipped up that I think does the operation you desire but in a slightly different way. 
    #!/usr/bin/perl
use strict;
use warnings;

    [download]
    Good! 
    my $var = '';
my @array = ();

    [download]
    No need for the initializations. 
    foreach my $line (<DATA>) {

    [download]
    While this does work, it is generally advised against as an extremely bad habit as it will slurp in the whole file at a time. Sometimes it doesn't make much harm, sometimes it is necessary, but it is not here and it would be recommendable not to spread bad programming habits amongst newbies. 
    exit;

    [download]
    No need whatsoever for this!
[reply]
[d/l]
[select]
      1. I think you're reading too much into my statement about @_ and $_. My point was really that using named variables is usually more clear (to me at least) than using no variable, relying in the default of either $_ or @_ in the function. Call it TIMTOWDI, call it style, but that's how I do it.

      Oh, and I definitely am NOT a "non-Perl programmer trying to hack at Perl". I've been coding Perl for 10 years now. It was my first programming language and remains my primary language to this day. Don't assume noobness just because someone's coding style is different than yours.

      2. Thank you. Old habit.

      3. There is need for the declarations under the strict pragma. I initialize when I declare as a matter of habit, to avoid "uninitialized" warnings. I also like giving all variables default values as another matter of personal style.

      4. I wasnt aware that line wasn't blazar-approved. I'll stop using it immediately. :) Seriously though, my coding style is situational. Since DATA is tiny in this case, I used that style. If you have a recommendation for the "newbies", you might want to actually write out some alternate code instead of just calling mine wrong and leaving it at that. That doesn't help anyone, does it?

      5. Again, old habit. It does no harm except take an extra quarter-second to type.
[reply]
        My point was really that using named variables is usually more clear (to me at least) than using no variable, relying in the default of either $_ or @_ in the function.

        This depends highly on the situation. You later say that your coding style is "situational," so I don't understand why you'd make a sweeping generalization like this. There are many cases where relying on $_ greatly enhances readability.

        @_ is a completely different matter, because -- as blazar says -- it's not just a "default" that you can avoid using. You use it to get subroutine parameters, and that's all there is to it. (Unless you're talking about using @_ as the default target for split, but I certainly hope you're not.)

        I've been coding Perl for 10 years now.

        I don't know enough about you personally to comment on your experience, but the length of time knowing how to use something is only a rough indicator of skill level. Consider how many people have been driving a car for decades, and are still terrible at it. :-)

        I initialize when I declare as a matter of habit, to avoid "uninitialized" warnings.

        You might as well just turn off the "uninitialized" warnings, if that's the case. Usually I start out with my variables all uninitialized, but use an algorithm that should initialize them before I use them. If that initialization doesn't happen, then I get a warning, and I know my algorithm is funky. It can be very helpful.

        I wasnt aware that line wasn't blazar-approved ... If you have a recommendation for the "newbies", you might want to actually write out some alternate code

        It's not just blazar's opinion. The standard way to get iterator behavior in Perl is a while loop. A filehandle is best used as an iterator. This is common practice.

[reply]
[d/l]
        First of all, when replying, please quote some relevant material of the original post to make it clear what it is that you're referring to. AFAIK there's no definite policy here about how to do so, so just pick an effective style you like and apply it.
        1. I think you're reading too much into my statement about @_ and $_. My point was really that using named variables is usually more clear (to me at least) than using no variable, relying in the default of either $_ or @_ in the function. Call it TIMTOWDI, call it style, but that's how I do it.
        Indeed, it's a matter of style. Incidentally I'm not really sure what you mean with the expression "the default of either $_ or @_ in the function". If you're talking about split in void context, then I agree with you, but that's one exception.

        OTOH let it be a matter of style/TIMTOWTDI-ness just as much as you like, I bet that when you talk you use the pronoun "it" quite often. Why do we use it? To make communication efficient. Perl, which has had a strong influence from natural languages, has $_ as an equivalent of "it" and you use it to make your code concise just as efficiently (readability/clearness-wise that is). Of course you shouldn't abuse it, but that's a whole different story.

        Obviously, just like with natural languages, you must know the language. This is why I made that comment about peple familiar with other languages trying to hack at Perl: compare 

        for my $line (@lines) {
    my @tmp=split ' ', $line;
    push @words, $tmp[0];
}

        [download]
        with 
        push @words, (split)[0] for @lines;

        [download]
        or 
        @words=map +(split)[0], @lines;

        [download]
        The former may be easier to understand to, say, a C programmer, but to any Perl programmer with some experience the latter ones are self-explanatory at a glance.
        Oh, and I definitely am NOT a "non-Perl programmer trying to hack at Perl". I've been coding Perl for 10 years now. It was my first programming language and remains my primary language to this day. Don't assume noobness just because someone's coding style is different than yours.
        I trust you on the word, if not for anything else because I do not have any reason to doubt it. But the amount of time spent coding in some language is only a rough indicator of the skills one can have with that language. In particular, as far as Perl is concerned (I think in connection with the proliferation of script kiddies of a few years ago) there is a surprising number of bad programming habits wide spreaded amongst supposedly "professional" programmers.
        2. Thank you. Old habit.
        What?
        3. There is need for the declarations under the strict pragma. I initialize when I declare as a matter of habit, to avoid "uninitialized" warnings. I also like giving all variables default values as another matter of personal style.
        Of course the single 
        use strict;  # along with
use warnings;

        [download]
        line is the most important line in 99% of code of 100% of Perl programmers. And declarations of course are required. Only in a few cases an explicit initialization is necessary to avoid "uninitialized" warnings. In particular 
        my @array = ();

        [download]
        never is, and IMHO it hardly adds any readability.
        4. I wasnt aware that line wasn't blazar-approved. I'll stop using it immediately. :) Seriously though, my coding style is situational. Since DATA is tiny in this case, I used that style. If you have a recommendation for the "newbies", you might want to actually write out some alternate code instead of just calling mine wrong and leaving it at that. That doesn't help anyone, does it?
        No need to write any "alternate code", whatever that is. I just suggested to use a while loop with the special while (<$fh>) syintax, and that's all that is really needed.

        The person you were answering to is evidently a newbie. Now chances are that he/she will pick up that bad habit too.

        5. Again, old habit. It does no harm except take an extra quarter-second to type.
        What? (I guess it's that exit().)

        Old habit? I don't know Perl4, but I think an explicit exit has never been necessary. It is only needed when you want to exit your program prematurely or with a particular code, period.

        Sorry to have conveyed the impression of trying to bash you. It was not my intention...

[reply]
[d/l]
[select]
Re^2: Yet another array problem
by Angharad (Pilgrim) on Jul 29, 2005 at 15:38 UTC
    Thank you. I will try that.
[reply]

In Section Seekers of Perl Wisdom