Re: Naming convention for variables, subroutines, modules, etc.. and variable declaration

[jbert]

My pet theory is that coding errors and complexity are generally proportional to "total variable scope" of the code in question.

Most of the good advice on coding (avoid global vars, use short methods, avoid objects with too many methods, etc) all acts to reduce the scope of variables (note that object member variables have scope across all methods).

Also, adding flags and the like to control loops increases the overall "Sum of variable scopes" in the code (by adding a var).

So...my general rule is to declare near/at the point of use. And if that's a long way from the top of the method, then the method is too big.

Basically, the more variables you have in scope at any one piece of code, the more combinations of possible states there are, and the harder it is to reason about the code. If a variable isn't in scope, you don't have to expend any precious mental juice wondering if it is related to the bug you are chasing.

Perhaps paradoxically, I very often introduce naming vars (e.g. my $badger = foo($some->{lookup}) for reasons of legibility (it acts to remove the need for a comment that the thing I am dealing with is a badger). (It's also driven by the fact that if something fails I have the values handily in vars which will interpolate nicely in an error string without any messing around with string concatenation). But these are often in very short scopes (a single loop or if() branch) - a few lines.

I can't work out if this contradicts my rule or if just adding another name for something which is already there (the expression) isn't as harmful (it doesn't multiply the number of states if it never changes). Any thoughts are appreciated.

[BrowserUk]

I concur almost exactly.

Whilst not decrying the practice of using a temporary "naming var" for clarity completely, they can often be avoided by other good naming choices.

In your example

foo( $badgers->{lookup} );

## or

foo( $some->{lookup_badger} );

## or

dealwithBadger( $some->{lookup} );

depending upon the circumstances.

[fenLisesi]

my %favorite_critter_of = (
                           andy  => 'badger',
                           larry => 'camel',
                           vito  => 'cat',
                           );
put_on_cover( $favorite_critter_of{ andy } );

Cheers.

[jbert]

Fair comment. It was a fairly bad example on my part. Certainly your underlying point that good naming is always important is something I heartily agree with.

Thinking about this more, if the expression is used more than once, I nearly always put in a naming var. I guess I then consider the code used in the expression to be repeated code, and effectively factor it out into one place and name it. On a small scale, this is pretty much the same as factoring out common code into a subroutine.

And since I'm often error checking/logging/throwing exceptions in production code, many/most/all such expressions would get a second usage in the error handling and hence get a name.

Thinking about my 'naming vars' versus 'variable scope' worry a bit more, I suspect that the reason this doesn't count as "more scope" to me is that I'm not using the variable as a variable. It's an additional name...it doesn't need the full privileges and rights of a variable. I guess I think of it as a read-only alias.

I guess I could use alias (isn't this recommended in PBP?). But I'm not sure really how perlish that is and whether it raises the bar of code comprehension too high. Maybe I just need to modernise :-)