Var scoping in ColdFusion is important we should all be aware of how it can affect our code if your not 100% sure take a look at this demo: http://devoneloper.blogspot.com/2011/04/coldfusion-var-scoping.html
My question and thought for today is ( presuming cf9 or railo ) should I var scope and declare my variable before use or should I rely on the local scope.
Our coding standards state we use the local scope ( even with cf8 where we var scope local and store all variables in the "local" scope ) but recently I have found myself wanting to not have to type local all the time and would prefer to declare my variables before use. I find var scoping more readable once you start nesting down or using keys in structors ect. I have moved on with this approach for ColdFusion work outside my day job.
Effectively the result is the same ( of ColFusion 9 atleast ) as you can see in this demo ( although the var method seamed to upper case the variable name i )
What are the majority of people out there using?
Demo Code:
Result:
In my opinion, the user-defined local scope that developers used before CF9 was a workaround for not being able to declare local variables anywhere inside a method. Once this limitation was removed, there really wasn't much of a need to create a true local scope.
ReplyDeleteSuffice to say, I prefer to var scope each variable rather than use the local scope. It just feels more natural to me.
local just looks so friggin terrible. Seeing code littered with local.this, local.that, local.whatever:
ReplyDeletecfif local.foo eq local.whooziwutzit is downright offensive to read
Well I don't know. You only have to define the variable once as local.something. Afterwards you can easily use something all the time.
ReplyDeleteI prefer writing local. since then I can even use it for the implicit variables create wir CFQUERY so that you have:
CFQUERY name="local.qry" ...
In addition I can dump the local scope and loop through it. That's why I tend to explicitly use it lately.
Gert
I have to agree with Marc here... I don't like and see no need for it. To me when you var scope a variable you are announcing that this variable is private to this method, no need for anything else.
ReplyDeleteI var scope.
ReplyDeleteIn the second function (varTest), wouldn't you also be able to refer to data.result1 as local.data.result1 (not that you necessarily want to)? Doesn't var scoping actually put the variable in the local scope implicitly?
Carl
I find a code readability drawback with 'var' scoping because the variables appear unscoped. In addition, if it's a large code block it's easiy to miss a var and then, if I'm correct, it defaults into the 'variables' scope - which can be bad.
ReplyDeleteSo I've gotten into a habit of var'ing a new struct named 'locvars'.
<cfquery name="locvars.getdata"...
This way I can implicitly create variables into that struct as if it were a native scope like 'local' (which I also dislike the 'local' scope, similar to why others mentioned above).
I'm not sure how I really feel about this fake scoping 'locvars' habit that I have gotten into, but I really don't like unscoped variables and I don't like 'local', so what else am I to do?
Another alternative is to use the attributes scope. You never need to 'var' anything nor use 'local'. It works implicitly. It's nice to use and is a valid native scope inside cffunction tags.
ReplyDeleteThe only potential downside is that it's possible to overwrite incoming variables - if a variable name is duplicated. But that's the case with any variables in any code block.
@Tony
ReplyDeleteYes I agree it was/is our way of working around not being able to var scope anywhere in a method ( cf8 )
@Marc I totally agree.
@Gert We name all our queries local.queryName and for query of query we escape the local in the sql ie :
select *
from [local.queryName]
@Carl yes that woudl work the same in CF9 at least.
I can see some minor advantage to 'local', but we use 'var' all the time. With one of our frameworks we do use attributes scope sometimes but we are very careful to var local function variables.
ReplyDeleteIf we miss one, another dev leaps on it during code review! *grin*