Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re: Coding style: truth of variable name

by jcb (Parson)
on Apr 19, 2020 at 04:01 UTC ( [id://11115773]=note: print w/replies, xml ) Need Help??


in reply to Coding style: truth of variable name

My general rule is to reuse a variable when the old value is no longer needed and the variable name also describes the new value, so I would prefer 2A but the comment explaining that $module is to be a canonicalized module name is very important. Creating additional lexicals is cheap, but not free in Perl. (Additional locals are essentially free in most cases in C since modern compilers allocate the entire stack frame at once.)

My fellow monk choroba made a good point about filtering input when you can, but I would also prefer 1A because that type of filtering at the beginning of a loop's block is idiomatic in Perl. Concision in this case is also useful in that the more concise code requires fewer VM steps because it avoids an extra lexical. Filtering the input is the best option, since grep iterates in C and reduces the number of iterations perl's VM must execute. This is a trivial concern in most cases, but can be serious in an inner loop.

Lastly, I think you meant "next unless -d $dir" in 1A, 1B, and 1C — "next if -d $dir" skips the iteration if $dir does name a directory and would be very confusing in all three cases.

Edited by jcb: Add missing caveat; thanks to GrandFather for pointing out my mistake.

Replies are listed 'Best First'.
Re^2: Coding style: truth of variable name
by GrandFather (Saint) on Apr 19, 2020 at 05:37 UTC
    My general rule is to reuse a variable when the old value is no longer needed

    Taken at face value that is terrible advice. A large part of understanding code is understanding the role of variables at any particular point. That is why choosing good variable names is important.

    If the role of the variable changes through the code then understanding the code becomes much harder. So maybe that wasn't what you meant by that statement?

    Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond

      I had forgotten an important detail. That should be "when the old value is no longer needed and the variable name also describes the new value". This balancing act is to avoid proliferating variable names like $file, $file2, $realfile, and similar problems that I have seen in existing code, including the questioner's example 1B.

      If the role of a variable can change, then (in my view, in Perl) the variable is defined in a scope that is too wide for the code as written. I often reuse the same name for another (similar) purpose later in a sub or script, for example, if iterating over two different sets of files, both foreach loops are likely to use foreach my $filename ..., but the variables are separate lexicals and $filename does not exist outside of those loops.

      Thanks for catching that — the idea that a variable name must describe its contents is something that I tend to assume goes without saying and that the questioner here seems to also tacitly understand, but that is an important detail that a new programmer might not yet know.

Re^2: Coding style: truth of variable name
by perlancar (Hermit) on Apr 19, 2020 at 07:22 UTC
    Ah yes, thanks for the correction about next unless.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others examining the Monastery: (4)
As of 2024-04-20 02:36 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found