So now that I've begun to use VarScoper I've really been surprised at how bad I am with var scoping. I mean - I'm the guy always complaining about other developers forgetting to var scope. But that's ok. I'm just happy I have the tool.
Here is a tip I wanted to share with people. This is probably obvious, but I missed it.
I wanted to start using varScoper for all my projects, but didn't want to have to keep editing the path to check different projects. What I didn't notice though was that his form for the varScoper was a GET form, which means all the attributes (path/file to check, recursive, etc) are in the query string.
I made a new folder in my Firefox Bookmark Toolbar and I've begun creating shortcuts for all the things I need to check.
Archived Comments
Anyone else use something like this:
<cfset var local = structNew()> or something similar? Seems a lot easier when have 10-20 variables.
Another idea I've been playing around with is using the arguments scope, especially when I only have a couple of variables.
<cfquery name="arguments._theQuery">
<cfreturn arguments._theQuery>
My issue with local is the amount of extra typing you do.
My issue with your second idea is that I feel it can confuse things. In general I treat the arguments as read only.
Now the question is why isn't this actually a part of CFEclipse yet? :)
The project is hosted at RIAForge, so why not make an enhancement request?
"I've really been surprised at how bad I am with var scoping"
So one of the top CF community member can't get it right but somehow all the other developers are. I think that is a red flag that this is a problem with the language. VarScoper is very handy while we have to deal with this but hopefully CF is improved so this is less of an issue going forward.
Well I can get it right - if I were to slow down a bit. ;) Most of my issues stem from rushing.
It's offical. You rock.
Our development team does regular code reviews for every project, and one of the many things we look for is unscoped variables. This tool is going to save us hours of time in handling that!
And, judging from what varScoper is telling us, our code reviewing needs a lot of work. :)
@Ray: yeah, I didn't mean it as a digg on you... just a suggestion that the language should change.
I was doing some error handling the other day and realized that cfcatch is put into variables scope. I mean really... how ridiculous is that. VarScoper doesn't find that problem or similar issues with cfftp and cfhttp. I've also noticed that "cfquery.executionTime" is thrown into variables scope as well and there is no var scoping can prevent it unless you specify a result variable to cfquery and var scope that.
I'm submitting those issues to the project on riaforge but just venting a bit.
To catch these issues I... 1) put all instance variables into a struct "variables.instance" 2) add a function to return or dump data in variables scope 3) run some tests 4) dump out variables scope. Basically anything that is directly in variables scope other than methods and "this" is an error. Injecting a method for inspecting variables scope and calling it as part of unit tests is probably the best way to catch these problems, but just isn't as easy as the varScoper tool.
@Rob - All I'm doing is sharing the good news. :)
@Dan - I don't know. I'd argue there is no need to var scope cfquery.executiontime since you don't end up using it. If you _do_ want to use it then you use result="X" and var scope X. There are no problems with cfftp and cfhttp unless you forget to use result=.
You are right that if you always provide a result variable and always varscope that variable and never use cfquery.executiontime and always varscope cfcatch and make sure to varscope every variable ever used in every cfc ever created then nothing bad could ever happen :-)
I woke up in a weird mood this morning. I'm just to going to stop there.
RE: using a struct. Are all variables stored inside protected the same as if you had scoped them on their own?
My O-O is bad. I envision it to be like a basket and if you scope the basket then everything inside it is covered.