http://www.perlmonks.org?node_id=1113446


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

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

Yeah, that isn't what DRY is about

  • Comment on Re^2: Convert undef to empty string in a hash

Replies are listed 'Best First'.
Re^3: Convert undef to empty string in a hash
by eyepopslikeamosquito (Bishop) on Jan 16, 2015 at 08:26 UTC

    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;
    is better written as:
    a_very_long_name += 42;
    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

      "...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»

        Ada is dead, but Pascal (Free Pascal and Delphi) does have += and stuff :)

      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.

        I'm a little bit saddened by the firm dismissal of (another) anonymonk

        The firm dismissal was warranted in my view because he was trolling. Most of what he said was deliberate nonsense -- and he knew it was nonsense -- designed to provoke an emotional response. He even owned up to that here.

        I'm a little bit saddened I fell for it though, with the thread quickly degenerating into emotion, not reason. I started with "Of GrandFather's two solutions, from the perspective of DRY, this one is better". I did not claim it as an absolute best solution. As you say, which solution is "better" depends on context and taste.

        I wish it had stopped there, but I was baited and responded emotionally. He had me going until he made the fatal mistake of mentioning sundialsvc4, which shocked me into realizing I had been sucked in. So I broke it off immediately. BTW, if you are really him, kudos on successfully baiting me again. :)

        Long variable names themselves may induce cognitive load
        Nowhere did I endorse long variable names. I assumed it self-evident that long variable names that differ in just one character (such as my example number_of_immortal_perl_monks vs number_of_immoral_perl_monks) show appalling taste and were used only to illustrate a point, while adding a bit of humour.

        The second suggested construct that uses values, might also increase cognitive load—for a perl novice—as it involves the concept of aliasing
        Of course, like writing style, programming style depends on the audience, the reader. Code read and maintained by Perl experts should be written in a different style to code maintained by Perl novices.

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