in reply to Re: What to test in a new module
in thread What to test in a new module

Reduce a ton of noise by eliminating quotes in hash keys when they don't contain anything other than alphanum and underscore. This: $vars{'error'} becomes this: $vars{error}

The reasons I single quote hash keys are:

  1. it makes them obvious as literals because a text editor highlights them.
  2. it differentiates them from interpolated hash keys - e.g. $vars{"key_$count"};
  3. it is easier to expand into variable keys

I think of 3 in the same way I been told that:

if ($condition) { $var = 1; }
is better than:
$var = 1 if $condition;
because we might want to add another statement into the code block.

Likewise, I feel:

$vars{'example'} = 1;
is better than:
$vars{example} = 1;
because we can expand it easily if necessary and create something like:
$vars{'example' . $count} = 1;

Others may have different opinions, clearly they do as there is a lot of code with unquoted hash keys, but this works for me in terms of clarity, expandability and maintainability. I don't see any downside to is on performance (please correct me if there is!) so I think I shall keep this one the way it is.

Replies are listed 'Best First'.
Re: Quoted hask keys (was: Re^2: What to test in a new module)
by Tux (Canon) on Jul 09, 2023 at 09:27 UTC

    Better is in the eye of the beholder and depends on too many preferences to define properly.

    e.g. run () if $chased is exactly the same code as $chased and run ();. It fully depends on your brain, the size of the team (1 is a valid size) and the style/rules the team has agreed on, the code consistency and the context which of the two to prefer. Personally I hate statement modifiers, as it does not fit my brain, so I prefer "expression and action" over "action if expression", but it it neither better nor worse.

    With your reasoning, *I* always prevent single quotes wherever possible, so that /when/ I see them, they are special. I made an exception in a CPAN module that I want to be as portable as possible, even under the most strict release versions of perl, even some experimental ones.

    I personally find $vars{"example $count"} way more readable and intuitive than $vars{'example ' . $count}

    Your milage may/will vary. Be consistent, which is way more important than being conventional.


    Enjoy, Have FUN! H.Merijn
      With your reasoning, *I* always prevent single quotes wherever possible, so that /when/ I see them, they are special.

      Precisely this. Conversely, if the code contains extra syntax over what is necessary then the reviewer (who might also be the author) needs to spend extra time considering why the extra syntax is there. Less syntax = less to parse = less to get wrong or be confused over. Less is more. :-)


      🦛

Re: Quoted hask keys (was: Re^2: What to test in a new module)
by tobyink (Canon) on Jul 10, 2023 at 08:43 UTC

    In my experience, there are two ways of using hashes. One is as a lazy-programmer's object. You see these kinds of hashes returned from database queries, received from REST API requests, etc. Something like this:

    my $uncle = { name => 'Bob', age => 45, };

    In these cases, the keys are an already-known set of strings, usually picked to be identifier-like (no spaces, weird punctuation, etc), so I will usually not quote keys in this kind of hash.

    The other way of using hashes is as basically a mapping from values of one type to values of another type. For example:

    my %ages = ( 'Alice' => 41, 'Bob' => 45, 'Carol' => 38, );

    Quoting the keys for this kind of hash is useful because you never know when another value is going to be added which isn't a safe identifier ($ages{"d'Artagnan"} = 62) plus it helps visually distinguish the second kind of hash from the first kind of hash.

    Do I consistently follow this rule? Absolutely not.