Stories
Slash Boxes
Comments
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.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • sub parse {
        my $feed = XML::Feed->parse(\shift->get_content);
        { feed_title => $feed->title,
          items => [
              map {
             {title => $_->title,
              link => $_->link,
              description => $_->content->body || $_->summary->body,
              date => $_->issued || $_->modified,
     
    • ew! Implicit return? You wouldn't have added an extra line by adding in those 6 letters; but you would have improved readability a fair bit. With what you've written I have to skim to the end to see what you're returning and then work my way upwards to see where the last statement starts. That might be okay when golfing, but that doesn't appear to be your intent. Damian spends almost 3 whole pages on the evils of implicit returns in "Perl Best Practices". See 197-199.

      Otherwise, well down on shrinki

      • I tend to write in an expression-oriented style, e.g. "map" instead of "foreach", and implicit return fits right in. I also try to limit vertical whitespace in order to fit more stuff on the screen. Both are just a matter of taste, though.

        I haven't read PBP, but from what I've heard about it, the "best practice" seems to be to ignore it. It has a few bits of good advice, but most seems arbitrary or just plain wrong.

        • As you haven't read PBP, I recommend you do so. Even if you then go and ignore most of the content, I'm sure you'll still learn a few things you didn't know before and become a better coder because of it. I'm dubious about it being a common recommendation from other experienced Perl programmers that the best practice is to ignore it, but I guess we know different people.

          I have no issue with you using map instead of foreach, and often use it myself, but I don't agree with leaving off the return. As a Perl trainer, I can assure you that this will completely baffle many less experienced coders. Some will assume your subroutine returns nothing, others will spend a lot longer than I did spotting where the last statement begins. But even with those arguments aside, relying on implicit returns can make your code wrong.

          For example (from Damian's book):

          sub find_second_odd {
              my $prev_odd_found = 0;

              # Check through args
              for my $num (@_) {
                  # Find an odd number
                  if(odd($num)) {
                      # Return it if it's not the first
                      return $num if $prev_odd_found;

                      # Otherwise, remember we've seen it
                      $prev_odd_found = 1;
                  }
              }
              # Otherwise we've failed
          }

          I know this is a contrived example. Providing good, easy to understand examples of problems which often bite you in much more complex systems is hard.

          So what's going wrong in that subroutine?

          What does this return for the following cases (also from Damian's book):

          find_second_odd(2..6);
          find_second_odd(2..1);
          find_second_odd(2..4);
          find_sec ond_odd(2..3);

          Hmm, that's right. 5, undef, empty string, empty string.

          Huh?

          Damian explains what's going on, on page 198. ;)

          • As you haven't read PBP, I recommend you do so. Even if you then go and ignore most of the content, I'm sure you'll still learn a few things you didn't know before and become a better coder because of it. I'm dubious about it being a common recommendation from other experienced Perl programmers that the best practice is to ignore it,

            That's not what I said, or at least not what I meant to say. Let's take a look at this [perl.com]: 1) okay; 2) okay if you use TDD, irrelevant otherwise; 3) a good way to end up with pointless boilerplate documentation; 4) good idea; 5) okay; 6) meh, enforcing human readability with a program is a recipe for failure; 7) uselessly vague; 8) okay; 9) again, useful iff TDD; 10) good advice that's usually given and/or taken the wrong way.

            So we've got 4 good ideas, 3 neutral ones, and 3 bad ones. Most of the good ones se