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 :-)
In reply to Re^3: Naming convention for variables, subroutines, modules, etc.. and variable declaration
by jbert
in thread Naming convention for variables, subroutines, modules, etc.. and variable declaration
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |