Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re: Re: Re: Balancing Coding Time And Code Quality

by diotalevi (Canon)
on Dec 08, 2003 at 16:17 UTC ( #313129=note: print w/replies, xml ) Need Help??


in reply to Re: Re: Balancing Coding Time And Code Quality
in thread Balancing Coding Time And Code Quality

Huh? The original code was a jot more complex than it needed to be and you think I'm nitpicking? The operation is in effect targetting both the input data and the output. I don't think that's unreasonable anyway, to expect the programmer to either modify the input or return the modification but not both simultaneously.
  • Comment on Re: Re: Re: Balancing Coding Time And Code Quality

Replies are listed 'Best First'.
Re: Re: Re: Re: Balancing Coding Time And Code Quality
by BrowserUk (Pope) on Dec 08, 2003 at 17:58 UTC

    Sorry diotalevi, but I guess this is (another) one of those things that we will have to agree to disagree about:)

    My comment was based upon your use of the word "style". It was intended to be a vaguely humourous way of indicating that style is in the eye of the beholder and critiquing on the basis of style is a little like saying that you don't like someone else choice of colour. You may not like the colour they favour, but saying that their chioce is wrong makes no sense.

    It's equivalent to saying that someones opinion is wrong. You may disagree with their opinion. You may be able to to prove that the facts their opinion is based upon are incorrect. But you cannot say that their opinion is wrong, because it is their opinion, and they alone are the final arbitars.

    The point you made about modifying the input list as a side-effect of a map statement has merit. In general, side-effects can be misleading and dangerous. However, in the specific case, as the input list was direct input from a file, and was summarily discarded after use within the map, the effect of the side-effect was also discarded and, as such, will never be available to the rest of the program or anywhere outside of the map. It is therefore impossible that it would ever have a detrimental "confusion factor" on the rest of the code.

    The alternative would be to read the file into an array and pass the array to chomp and then supply the chomped array to the map in order to construct the hash. Then discard the chomped array.

    All of which would buy you absolutely nothing, as the array would still have been modified as a side-effect of passing into chomp. All that would have been achieved is the unnecessary and confusing creation of a temporary array for no good purpose whatsoever.

    Under slightly different circumstances, the use of chomp within the map could be considered a bad practice. On those occasions where that would be so, the reason for it being a "bad practice" have everything to do with sound, quantifiable, technical reasons...and nothing whatsoever to do with "style".

    The purpose of my tongue in cheek analogy was to emphasis that your positioning a (sometimes valid) technical critique, under the banner of "style" was itself a dubious practice.

    I might say, that your critique itself was "bad style", but then I'd be guilty of exactly the same sin as (IMO) you were.


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    Hooray!
    Wanted!

      Oh I see. It is "style" because it made no technical difference to the code in question but would be a "style" error if the same technique were re-used elsewhere. I also call the multiple-side effect code a style error because that may be what the coder intends in that other circumstance. It may also be that the effect is similarly meaningless. My thought is that this is sort of like the use of globals and lexicals - you can write perfectly valid code using either but if you code with stylistic preference you avoid a class of errors.

        Okay. It seems we're down to an even more ephemeral distinction -- the meaning, or rather our interpretation, of the word "style".

        I accept your POV, whilst continuing to disagree with it:)

        Peace and love!


        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "Think for yourself!" - Abigail
        Hooray!
        Wanted!

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://313129]
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (6)
As of 2018-06-22 11:36 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?



    Results (124 votes). Check out past polls.

    Notices?