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.
Comment 1 written by Brad Roberts on 22 May 2008, at 12:01 PM
<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>
Comment 2 written by Raymond Camden on 22 May 2008, at 12:10 PM
My issue with your second idea is that I feel it can confuse things. In general I treat the arguments as read only.
Comment 3 written by Erki Esken on 22 May 2008, at 12:21 PM
Comment 4 written by Raymond Camden on 22 May 2008, at 12:25 PM
Comment 5 written by Dan Roberts on 22 May 2008, at 6:06 PM
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.
Comment 6 written by Raymond Camden on 22 May 2008, at 8:02 PM
Comment 7 written by Rob Barthle on 23 May 2008, at 8:42 AM
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. :)
Comment 8 written by Dan Roberts on 23 May 2008, at 9:18 AM
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.
Comment 9 written by Raymond Camden on 23 May 2008, at 9:57 AM
@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=.
Comment 10 written by Dan Roberts on 23 May 2008, at 10:11 AM
I woke up in a weird mood this morning. I'm just to going to stop there.
Comment 11 written by Rob Barthle on 21 April 2009, at 3:03 PM
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.
[Add Comment] [Subscribe to Comments]