in reply to Convert undef to empty string in a hash

$foo{$_} = $foo{$_} // '' for keys %foo;

[download]
Both of GrandFather's solutions are "better" than yours because your solution violates DRY. That is, this class of coding error: 
$Foo{$_} = $foo{$_} // '' for keys %foo;    # oops I meant $foo not $F
+oo

[download]
simply cannot occur with good ol' Gramps' solutions.

Of GrandFather's two solutions, from the perspective of DRY, this one is better: 

$_ //= '' for values %foo;

[download]
because the name foo is mentioned only once.

Replies are listed 'Best First'.
Re^2: Convert undef to empty string in a hash
by Anonymous Monk on Jan 16, 2015 at 07:46 UTC

    our solution violates DRY...from the perspective of DRY, this one is better:

    Yeah, that isn't what DRY is about

[reply]

      Yeah, that isn't what DRY is about
      Well, that is a matter of interpretation and you did not provide any citations to support your interpretation.

      From Don't Repeat Yourself (O'Reilly)

      Every line of code that goes into an application must be maintained, and is a potential source of future bugs. Duplication needlessly bloats the codebase, resulting in more opportunities for bugs
      I contend that: 
      a_very_long_name = a_very_long_name + 42;

      [download]
      is better written as: 
      a_very_long_name += 42;

      [download]
      because (the completely unnecessary) duplication of a_very_long_name is eliminated thus eliminating a "potential source of future bugs" and reducing "opportunities for bugs".

      Of course, DRY is much broader than that. Yet that doesn't mean my interpretation of it here is wrong. Indeed, the wikipedia DRY page gives a very broad interpretation:

      a principle of software development, aimed at reducing repetition of information of all kinds

[reply]
[d/l]
[select]
        "...is better written as..."

        Yes and no. I'm a bit unsure about this. Please see Assignment and increment operators (like += and ++ in C)" for a pascalish or adaistic point of view about this - as you like:

        "Ada provides these computations, of course, but not as special operators. Their exclusion is a judgement call. In some cases, they can make individual statements simpler to read. Overall, most code is clearer and more reliable without them. It's easy to misread "x += expression" as "x := expression" instead of "x = x + expression", especially if this line is buried in a sequence of assignments with varying assignment operators. Further, typos are less likely to result in valid (but erroneous) code. Note that "+" and "=" are on the same key on most keyboards, and "-" is next to it. "+=" and "-=" are easy fumbles for "=", or for each other."

        Best regards, Karl

        «The Crux of the Biscuit is the Apostrophe»

[reply]

        I'm a little bit saddened by the firm dismissal of (another) anonymonk. Quoted wikipedia interpretation is so broad it's borderline meaningless. But when a more specific definition is put forth, it is rejected.

        The book you refer to ("97 Things Every Programmer Should Know") draws on many programmers' meditations. Quoted from the preface:

        The contributions do not dovetail like modular parts, and there is no intent that they should—if anything, the opposite is true. The value of each contribution comes from its distinctiveness. The value of the collection lies in how the contributions complement, confirm, and even contradict one another.
        Eyepops, your appeal to authority is bogus. There is no one best way here.

        Long variable names themselves may induce cognitive load. The second suggested construct that uses values, might also increase cognitive load—for a perl novice—as it involves the concept of aliasing.

[reply]
[d/l]
      A reply falls below the community's threshold of quality. You may see it by logging in.

In Section Seekers of Perl Wisdom