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.

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 +=.

my $location = $mainHash->{$hashType}{$regionID}{MetricType}{$resultHa
+sh->{Location}};
$location->{$yearMonthDateList[$start]} += $resultHash->{Value};
[download]

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};
[download]

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};
[download]

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};
}
[download]

If you make $mainHash an object it might collapse into

{
   $mash->mertem( $mash->mertem + $value );
}
[download]

If your varnames were shorter more obvious, it'd look different Re: Perl Best Practices for naming variables, About the use of the plural form for the name of variables, Re^3: What would be the easier way, Re^8: What would be the easier way, Re: Cool way to parse Space Separated Value and CSV files, Re: Perl Best Practices for naming variables, Re: What are the most basic, generic aspects of programming?, Pronounceable syntax or beloved punctuation?, How do you pronounce variable names?, How do I pronounce all this stuff, How do you pronounce "::"?,

$main $region $metric $hash %res @ymDates

$$main{$hash}{$reg}{MetricType}{$$res{Location}}{$ymDates[$start]} = $
+$main{$hash}{$reg}{MetricType}{$$res{Location}}{$ymDates[$start]} + $
+$res{Value};

$$main{$hash}{$reg}{MetricType}{$$res{Location}}{$ymDates[$start]} += 
+$$res{Value};
[download]

Of course, its harder to come up with varnames without good context :) But mainhash and hashtype stand out as having too many generics not easily substituted :)

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.