Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • What silly complaints. for ( @foo ){ print "$_\n" } is fine but print "$_\n" for @foo; is not? The obfuscatory bit, if there is one, is Perl’s strange attractor, the $_.

    I never followed the argument that trailing control flow constructs are somehow obfuscatory. What kind of retard does someone have to be if they understand if( $foo ) { bar( $baz ) } but is totally lost as soon as it’s written bar( $baz ) if $foo? I’m not using “retard” in the name-calling sense either; I mean

    • Clearly the mark of a great programming language (if you're not a Lisp hacker anyway) is when a complete idiot who's never programmed before could maintain your code, not that that's pretty much the anti-pattern or anything.

      (You should name your default variable $it so everyone knows it's a pronoun.)

      • An entire paragraph written using “it” as the subject in every sentence isn’t very readable. There are good reasons to want to use a named iterator variable. Mind, I don’t think $_ is inherently obfuscatory and I have no qualms about using it, though I do consider each case carefully. If you’re iterating over a list returned directly from a somewhat complex expression, then a well-named iterator helps document intent. And there’s only one $_, so in those cases where need

        • by perrin (4270) on 2006.01.09 15:52 (#45594) Journal
          Postfix "if" can be quite dangerous. There's a significant bug you can hit if you write a line of code that defines a lexical variable and has a postfix if. It's very hard to spot these. Postfix "for" doesn't have any dangerous bugs like this that I'm aware of.