Chad Perrin: SOB

1 October 2007

rule of thumb for $_ in Perl

Filed under: Geek — apotheon @ 01:45

Perl makes use of an implicit scalar variable, $_. The $_ variable is assigned a value whenever you write code that requires a scalar value to be passed to something without actually passing it explicitly. For instance, if the first line of your foreach loop looks like this:

foreach (@foo) {

. . . you’re going to get each element of @foo being available to the code executed inside the loop, one iteration at a time, in the $_ variable. As such, you might write code like this:

foreach (@foo) {
  print $_;
}

Let’s ignore for the moment that you could, with a very simple loop like that, put the print part before the foreach part, all on one line, and skip the braces entirely. It’s just a bit of very simple example code.

Anyway . . . a lot of people find $_ ugly and even obfuscatory. The answer for most is to always avoid $_ at all costs. Some even take that to the unreasonable extreme of avoiding Perl, as if the entire language is tainted by their personal distaste for the $_ variable. In the case of continuing to use Perl while avoiding $_, however, you might end up with code like this:

foreach $bar (@foo) {
  print $bar;
}

This way, you can name your iterator scalar descriptively, clarifying the code. I absolutely agree that this is an excellent approach to take — but I also believe there are times that the inclusion of the $_ variable in the Perl language can provide some benefits, not only for the coder, but for whoever has to read the code again later. The key is that you should never have to actually type the dollar and underscore characters to access that variable’s contents. You could, for instance, do this:

foreach (@foo) {
  print;
}

That is the sort of behavior that makes it possible for a Perlist to do things like print foreach @foo;, in fact — which can add even more clarity to your code when the contents of your loop consist of a single (short) line of code. Just remember, when dealing with Perl, that $_ is an implicit variable, and should only be used implicitly if at all possible. When the code in your loop (or wherever else you are using $_, whether you use it explicitly or implicitly) is brief enough, consider whether implicit use of $_ would clarify your code. If it wouldn’t, or you basically can’t use it with your code as written, consider whether one of the following is true:

  1. You should probably avoid using $_ there, and use a different, explicit variable instead.
  2. Your code might benefit from a little refactoring so that use of an implicit variable would help clarify things.

In other words, the rule of thumb for $_ in Perl is as follows:

If you have to use it explicitly, use something else instead.

That rule of thumb is not just “never use it”. It’s there for a reason.

(NOTE: crossposted)

Learn to spell! (yet another reason)

Filed under: Cognition,inanity — apotheon @ 10:39

I was reading some discussion on ruby-talk (yes, again — I do that pretty much daily, but don’t usually feel inspired to talk about it here) where a non-native English speaker asked a question. The question was about whether to start out with Ruby or Python, or something to that effect, and of course Ruby got the most votes (it being a Ruby discussion venue, not a Python venue). I noticed something troubling about the responses, however:

Some of these people were using words they knew how to use, but didn’t know how to spell.

When typing a message for someone who is not a native English speaker — and more to the point is obviously not a native speaker, the English being somewhat broken — it is imperative that you spell your words correctly. The reason for this is, of course, because non-native speakers are even less likely than usual to know every single word you use, and misspelling words makes them very difficult to look up in a dictionary.

Obviously, everyone can make a typo now and then, and can even miss it on a read-through to check for typos before hitting Submit. It’s also possible for someone who is generally an excellent speller to make an actual spelling error. In most cases, however, people who misspell things in communications over the Internet have a tendency to just be piss-poor spellers, and don’t give a crap.

Well, fine. I’ve come to realize that I can’t fix the whole world. So some people are willfully ignorant asses that can’t even be bothered to use an automated spell-checker for official correspondence, let alone a programming community mailing list — and, frankly, the programming community mailing lists I’ve followed over the years have been better about spelling than certain other online discussion venues. I guess I can live with that. On the other hand, when some inconsiderate, unthinking schmuck posts a relatively short email with more than half a dozen misspellings of words that aren’t all that commonly used in direct response to a speaker of broken English, there’s something desperately wrong with the way that person interacts with the world. Do you really expect someone from, say, Bangladesh who can barely string sentences together to understand a statement that centers on the so-called word “esotheric”? Not only is “esoteric” a, um, slightly esoteric word to many native English speakers, but when misspelled like that it suddenly becomes very difficult to look up for a definition.

If you know you have a spelling problem, and you’re writing (especially about technical subjects) for an audience of non-native English speakers, please — for the love of gob and all that’s wholly — use a damned speel chucker. It’s just common courtesy, you uncouth hick.

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License