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


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

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

Replies are listed 'Best First'.
Re^4: Convert undef to empty string in a hash
by karlgoethebier (Abbot) on Jan 16, 2015 at 18:11 UTC
    "...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 :)
        "Ada is dead..."

        Yes sure. And my cell phone is stronger than your fax machine.

        Regards, Karl

        «The Crux of the Biscuit is the Apostrophe»

Re^4: Convert undef to empty string in a hash
by Anonymous Monk on Jan 17, 2015 at 09:28 UTC

    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.

        > I wish it had stopped there

        It's never too late ... ;D

        Cheers Rolf

        PS: Je suis Charlie!

        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 owned up to no such thing.

        I owned up to comparing you to the that guy because you used his exact words -- as soon as I recognized the words, I went ugh -- but I had to point it out because its a real weak argument -- but that got you to stop posting on the actual topic

        looks wrong? DRY isn't about looks

        Not all ideas put forth are accurate, and exploring them isn't trolling -- resorting to ad-hominem doesn't explain anything

        I'll try to pick it up , the Don't repeat yourself page links to interview with authors of the book Orthogonality and the DRY Principle

        Dave Thomas: Most people take DRY to mean you shouldn't duplicate code. That's not its intention.

        DRY says that every piece of system knowledge should have one authoritative, unambiguous representation. Every piece of knowledge in the development of something should have a single representation. A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation.

        Saying one version is shorter, more perlish, more clear -- that all makes sense

        Saying its more DRY doesn't make sense

        Saying the maintenance programmer goes ... thats a great topic if the exploration goes beyond "because I said so, you're a noob"

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