good chemistry is complicated,
and a little bit messy -LW
Re^4: Yet another array problemby blazar (Canon)
|on Jul 31, 2005 at 15:07 UTC||Need Help??|
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
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
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
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...