Re^3: Convert undef to empty string in a hash
by eyepopslikeamosquito (Archbishop) on Jan 16, 2015 at 08:26 UTC
|
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
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
| [reply] [Watch: Dir/Any] |
|
Ada is dead, but Pascal (Free Pascal and Delphi) does have += and stuff :)
| [reply] [Watch: Dir/Any] |
|
|
| [reply] [Watch: Dir/Any] |
|
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] [Watch: Dir/Any] [d/l] |
|
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.
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
|
A reply falls below the community's threshold of quality. You may see it by logging in. |