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];
}
with
push @words, (split)[0] for @lines;
or
@words=map +(split)[0], @lines;
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;
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 = ();
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] |
