in reply to Re^3: Convert undef to empty string in a hash
in thread Convert undef to empty string in a hash

This node falls below the community's threshold of quality. You may see it by logging in.

Replies are listed 'Best First'.
Re^5: Convert undef to empty string in a hash
by LanX (Saint) on Jan 16, 2015 at 09:23 UTC
    You didn't understand DRY.

    DRY doesn't care about shortness!

    It's about avoiding to repeat identifiers, hence

    • avoiding typos
    • reducing maintenance overhead
    • improve readability

    Cheers Rolf

    PS: Je suis Charlie!

    A reply falls below the community's threshold of quality. You may see it by logging in.
Re^5: Convert undef to empty string in a hash
by eyepopslikeamosquito (Archbishop) on Jan 16, 2015 at 10:08 UTC

    So yeah, this is shorter $_ //= '' for values %foo; than $foo{$_} //= '' for keys %foo;, and sure, you can say its more DRY, but DRY doesn't care about it, its the same one line talking about the same one variable %foo, nothing that can get out of whack because of any duplication
    Actually, it can easily get out of whack:
    $foob{$_} //= '' for keys %foo;
    Now the maintenance programmer must ask: is this really the intent ... or is it a typo?

    Using the name once only makes the intent clearer, that is:

    $_ //= '' for values %number_of_immortal_perl_monks
    makes it clear, at a glance, that the intent is to update a single hash, while:
    $number_of_immoral_perl_monks{$_} //= '' for keys %number_of_immortal_ +perl_monks
    gives the maintenance programmer a headache.

    Finally, with:

    $foo{$_} //= '' for keys %foo;
    to rename the foo hash to a better name you must change it in two places, rather than one, so there is (an admittedly small) chance of error when you are doing search-and-replace in your editor (code refactoring IDEs help here).

      Actually, it can easily get out of whack: ... Now the maintenance programmer must ask: is this really the intent ... or is it a typo?

      Why must he ask that?

      Using the name once only makes the intent clearer, that is: makes it clear, at a glance, that the intent is to update a single hash, while gives the maintenance programmer a headache.

      All three are equally clear at a glance (I glanced at them, equally clear, no headache)

      Finally, with: to rename the foo hash to a better name you must change it in two places, rather than one, so there is (an admittedly small) chance of error when you are doing search-and-replace in your editor (code refactoring IDEs help here).

      Well, if you're going to change the name, you already have to change it in more place than that one line ... and if you make a mistake, perl will tell you, as will your test suite ...

      But why would you have to rename the hash to a better name after writing lines of code? Why wouldn't you start with a better name to begin with in the start if the beginning before writing the many lines of code? :D

        Why must he ask that?
        Because it looks wrong. And is not accompanied by a comment warning that, though it looks wrong, it is intended. Since you ask that question, I assume you haven't any experience maintaining large legacy code bases, with minimal test coverage, where the original authors have long since left the company.

        All three are equally clear at a glance (I glanced at them, equally clear, no headache)
        Yet you did not notice the difference between "immoral" and "immortal"?