in reply to Idioms considered harmful

You say (correctly, IMO) that the idiom requires knowledge of:

  1. local;
  2. the input record seperator, $/;
  3. ARGV magic;
  4. list assignment greediness.

FWIW, I think that's a useful list. It could even be seen as a succinct analysis of how the idiom works. It made me appreciate how much Perl I have learned over the past year.

I knew all of the items except for no. 3, the ARGV magic, which Aristotle pointed out to me, and which I then went off and learned about in perlop (section: "I/O Operator"). I have started using the idiom in my own production code (which is not subject to a code review, except by myself).

I do appreciate your point of view, nonetheless I think it goes too far.

Your point about coworkers really is very subjective. It doesn't say anything about how valid the idiom is *as an idiom*. But that's the whole point, I think, idioms are subjective. And as others have mentioned already, it will always be near impossible to draw a line or boundary for something subjective like this.

Yes the corporate/coding_standard reaction to this will often be to just ban it, but that doesn't make it right. Tomorrow they could be banning <> or $_ as well.

Replies are listed 'Best First'.
Re^2: Idioms considered harmful
by Aristotle (Chancellor) on Oct 16, 2002 at 10:55 UTC

    As a sidenote, I always use the diamond operator magic in commandline tools. It has significant advantages: considering the scripts are usually short, getting all I/O dealt with in a single while(<>) is really convenient, and it deals with any number of files without me having to write an extra loop over @ARGV. I also have these scripts write any actual output to STDOUT and errors or other messages strictly to STDERR, so that the user can redirect or pipe the result (or just let it print to screen) at their convenience. And because these handles are given, I don't need to deal with opening output files either. Also since the diamond operator peeks at @ARGV at the time it is invoked, I can munge any commandline parameters with Getopt::* beforehand, and it works out beautifully.

    Bottom line, I can have my cake and eat it too: a lot less code, and consequently work, but maximum flexibility. Perl rocks that way.

    Makeshifts last the longest.