Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Re^3: Way to make this code better.

by QM (Parson)
on Aug 17, 2015 at 09:23 UTC ( #1138859=note: print w/replies, xml ) Need Help??

in reply to Re^2: Way to make this code better.
in thread Way to make this code better.

$r stands for response, $d for data
This would never pass code review in many shops. See for example Single Letter Variable Names Still Considered Harmful.

If $r is for the response or result, say $response or $result. Better yet, call it something meaningful, related to what it actually is, and not whether it's an input parameter or gets returned. In the OP, this might be $prettified_registers or somesuch.

To make my point for me, line 50 conveniently provides:

return( $c{_err_} );

Note that $c is not mentioned in the OP code snippet anywhere else, it is not obvious what it is, etc.

A slightly weaker complaint is using literal strings to index hashes (_err_). In a large project, typos abound. This code may never be exercised in testing, and a typo here will not be caught until much too late. Debugging typos in hash keys is awkward. And there is no "great" solution in Perl. A reasonable stab is to use variables to hold the literals, such as:

my $some_key = q/Some Key/; $hash{$some_key} = 42;

Then at least, the compiler will complain for most typos. But it won't complain if you mix in literals, so you have to be consistent. If you're implementing classes anyway, you can then use object accessors instead, and check that way.

Quantum Mechanics: The dreams stuff is made of

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1138859]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (4)
As of 2018-05-28 02:03 GMT
Find Nodes?
    Voting Booth?