in reply to Quoted hask keys (was: Re^2: What to test in a new module)
in thread What to test in a new module

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

Replies are listed 'Best First'.
Re^2: Quoted hask keys (was: Re^2: What to test in a new module)
by hippo (Archbishop) on Jul 09, 2023 at 11:21 UTC
    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. :-)


    🦛