Var Scoping Tool

So, pre-MX my big thing was locking. Post MX (really, CF5) my big "let me get all anal" thing is var scoping. As you have heard me say time after time on this blog, if you forget to var scope, you will end up in big trouble. (That's right, big trouble. Human sacrifice, dogs and cats living together - mass hysteria.)

Mike Schierberl has released a cool new tool to help solve that problem, the varScoper. This tool lets you examine your source code for potentially missing var statements. It will return a report of all the possible matches.

Whats cool about this tool is that it even found mistakes in my code. Not to say I'm perfect - but I know I definitely look out for it and I still missed things. There is an online demo which uses a copy of BlogCFC as one of it's samples. It found a few false positives, but it found some real issues as well. (Fixed in the latest release!)

Comments (20) Jul 20, 2006 2:52 PM Views: 4099

Comments

[Add Comment]
Love the Ghostbusters reference...
# Posted By Sean Coyne | 7/20/06 3:23 PM
My favorite line in that movie: "Ray, what did you do?"
# Posted By Raymond Camden | 7/20/06 3:26 PM
Does it look for var scoped variables that aren't used? That would be a great way to find the most common source of trouble I have seen -- typos in the var declaration.
# Posted By Nathan Dintenfass | 7/20/06 4:08 PM
Well, if you typo, it would catch the unscoped one, but if you had a var x and you never use x, I don't think it would catch that. Maybe recommend it to him.
# Posted By Raymond Camden | 7/20/06 4:19 PM
It will catch typos in the var declaration, take a look at coldspring, it caught a case where a var was declared as "funtion" and then referenced as "function". If you take a look at the dump output you can see that I actually track which variables are "used" and "unused", but this only tracks variables that are "used" by setting. For example, it would identify that foo was used if you specified (cfset foo = ""), but it would not identify that foo was used if you specified (cfset myfunction(argument=foo))
# Posted By Mike Schierberl | 7/20/06 4:31 PM
Dammit Ray. Everytime I think i got my code perfect you have to show me somethign that makes me go back and rewrite stuff. THANKS! (no seriously, thanks! This is a great tool!)
# Posted By TJ | 7/20/06 7:32 PM
CFUnit also has a test that checks for Var scope. Would love to see something like this included in CFEclipse also.
# Posted By Daniel D | 7/20/06 7:37 PM
Don't thank me, thank Mike. :)
# Posted By Raymond Camden | 7/20/06 8:01 PM
Yes, this is definitely quite useful and I'll be using this from now on . . . thanks, Mike! Looking forward to seeing it rolled into CFEclipse . . .
# Posted By Lola Lee Beno | 7/20/06 8:20 PM
Hurrah ! One of the reason I like the internet is because it saves me having to write stuff :-)
I'm off to run our code through it :-)
# Posted By Tom Chiverton | 7/21/06 3:23 AM
Good post!
# Posted By Gabriel | 7/21/06 4:57 AM
Well, if you typo, it would catch the unscoped one, but if you had a var x and you never use x, I don't think it would catch that. Maybe recommend it to him.
I think so!!!
# Posted By Gabriel | 7/21/06 7:36 AM
There is an online demo which uses a copy of BlogCFC as one of it's samples. It found a few false positives, but it found some real issues as well. (Fixed in the latest release!)
Cool!!
# Posted By Danielle | 7/21/06 11:37 AM
Ray,

in regards to this var scope I do things a little different..

What about doing something like this?

I var the struct then return that in cfreturn

<cffunction name="foo">

<cfscript>
var stReturn = StructNew();
stReturn.bSuccess = True;
stReturn.message = "";
stReturn.data = "";
stReturn.stError = structNew();
</cfscript>

<!--- Do some query here qGetSomethingFromDatabase --->

<cfscript>
if( Not qGetSomethingFromDatabase.RecordCount )
{
stReturn.bSuccess = false;
stReturn.message = "Some message about no records found"
}
else
{
stReturn.bSuccess = true;
stReturn.data = qGetSomethingFromDatabase;
}
</cfscript>

<cfreturn stReturn>

</cffunction>
# Posted By Carl V | 7/22/06 7:43 AM
Carl-

The code example above is 90% ok. Scoping a struct with a var statement works, in this case though my tool wouldn't pick it up because it is in cfscript. Also, in your case you would definitely want to include the following statement as well.

var qGetSomethingFromDatabase = "";

cfquery statements create variables based on the name attribute, and as a result could be thread unsafe.

-Mike
# Posted By Mike Schierberl | 7/22/06 10:27 AM
Carl, I've seen other people who return structs like this. I don't care for it. I thnk you should return the data and just that. I can go into it more, but thats my opinion.
# Posted By Raymond Camden | 7/22/06 8:16 PM
Hi Ray -

Could you go into detail as to why you don't care for creating a local struct as a shortcut to make sure all the variables in your functions have a "local scope".... as in the following example, posted in various places across the internet:

<cffunction name="myFunction">
<!--- define a local scope --->
<cfset var local = structnew()>
<!--- use whatever vars we like in the local scope --->
<cfset local.firstvar = "Hello">
<cfset local.another = arraynew(1)>
<!--- run a query without declaring the var first --->
<cfquery name="local.qMyQuery" datasource="blah">
...
</cfquery>
</cffunction>
# Posted By Aaron Longnion | 7/25/06 4:49 PM
It isn't for any performance/security reasons, it is just my personal preference. I don't know why, but I like knowing all the variables being used inside the method. Maybe I'm anal that way.
# Posted By Raymond Camden | 7/26/06 8:50 AM
I should have mentioned to take note of the comments in Brian Kotek's post - that is where the discussion regarding the 'local' scope is.
# Posted By todd | 10/5/06 5:19 PM
[Add Comment]