Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

$var{el} += 1 vs $var{el} = $var{el} + 1

by banesong (Acolyte)
on Aug 13, 2013 at 14:11 UTC ( [id://1049282]=perlquestion: print w/replies, xml ) Need Help??

banesong has asked for the wisdom of the Perl Monks concerning the following question:

I have what is probably a stupid question, but I am trying to figure out the best practice.

I have a large data set that I am iterating over, and am creating aggregate totals from. Depending on a variety of conditions, I need to then update the total. While currently getting the correct totals, the readability of the code stinks; it uses the following format.

$$mainHash{$hashType}{$regionID}{MetricType}{$$resultHash{Location}}{$yearMonthDateList[$start]} = $$mainHash{$hashType}{$regionID}{MetricType}{$$resultHash{Location}}{$yearMonthDateList[$start]} + $$resultHash{Value};

So, is there a reason (technically, best practice, etc) that I should not just use this format:

$$mainHash{$hashType}{$regionID}{MetricType}{$$resultHash{Location}}{$yearMonthDateList[$start]} += $$resultHash{Value};

Caveat: The mainHash value will be blank the first time it is referenced.

Thanks. Again, this is probably a simple question, but I was unable to find a reasonable answer through search.

T

Replies are listed 'Best First'.
Re: $var{el} += 1 vs $var{el} = $var{el} + 1
by kennethk (Abbot) on Aug 13, 2013 at 14:25 UTC
    Any response you'll get here is 'IMHO', so the important thing is really readability for you, both today and in a year when you have to maintain this code.

    From my perspective, using a compound assignment operator improves the legibility dramatically. With the large number of hash keys present, it'd be very easy to get confused whether the keys are all the same. += makes your intent much more obvious. It also protects you from potential typos.

    Make sure in migrating this code that you are actually reading the code properly. It be a real shame to put time and energy into improving the readability and break the code in the process.


    #11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.

      I actually just fixed a couple of problems where the hash got deeper on the left, and not on the right (e.g. extra level was added).

      I think that we will be changing the sub to use a more sanely readable format with +=.

Re: $var{el} += 1 vs $var{el} = $var{el} + 1
by choroba (Cardinal) on Aug 13, 2013 at 14:35 UTC
    Note that if you dereference the same keys several times, it might save you some runtime (not talking about readability) by createin variables for them:
    my $location = $mainHash->{$hashType}{$regionID}{MetricType}{$resultHa +sh->{Location}}; $location->{$yearMonthDateList[$start]} += $resultHash->{Value};
    لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ

      Okay, so that begs a question - what is the impact on performance between:

      $totalsHash{$resultHash{SomeKey}} = $resultHash{SomeKey}{AltValue};

      vice

      my $resultKey = $resultHash{SomeKey}; $totalsHash{$resultKey} = $resultHash{$resultKey}{AltValue};

      This is assuming I am referring to the SomeKey value multiple times. I would assume the second scenario is more efficient.

        It depends on the number of invocations. Use Benchmark to check.
        لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ

        Okay, so that begs a question - what is the impact on performance between:

        irrelevant :)

        Throwing memory at the problem (extra $scalar) is slightly faster than extra (double-1) hash lookups

        But you meant to type

        $someKey = $resultHash{SomeKey}; $totalsHash{ $someKey } = $$someKey{AltValue};
Re: $var{el} += 1 vs $var{el} = $var{el} + 1
by Anonymous Monk on Aug 13, 2013 at 14:31 UTC

    So, is there a reason (technically, best practice, etc) that I should not just use this format:

    How big is your monitor? :)

    FWIW, a best practice policy might outlaw $$fa{$fa}{$fb}{$fc}{$fa}{$fq}{$fp} or even $fa->{$fa}{$fb}{$fc}{$fa}{$fq}{$fp} and demand intermediates or even helpers

    { use Data::Diver qw/ Dive /; my $metric = Dive( $mainHash , $hashType , $regionID, 'MetricType' + ); my $cirtem = Dive( $metric, $$resultHash{Location} , $yearMonthDat +eList[$start] ); $cirtem += $$resultHash{Value}; }

    If you make $mainHash an object it might collapse into

    { $mash->mertem( $mash->mertem + $value ); }
Re: $var{el} += 1 vs $var{el} = $var{el} + 1 (varnames)
by Anonymous Monk on Aug 13, 2013 at 14:56 UTC

      The variable and key names have been changed to protect the (not so) innocent. We do have long-ish variable names as rule for clarity's sake (e.g. movementCount or movementType). It does sort of decrease readability, but increases comprehension six months later when a code review occurs.

        You may consider investing in lock_keys from Hash::Util. It fixes which keys are allowed in a hash, at the cost of a small amount of speed, and thus protects you from hash key typos.


        #11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://1049282]
Approved by marto
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others studying the Monastery: (5)
As of 2024-03-29 10:50 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found