Skip to content

varScoper 1.1 – now with cfscript parsing

by Mike on October 7, 2007

That’s right, my varScoper tool now supports cfml written within cfscript blocks.  Please note that this is still somewhat experimental, but seems to handle quite a few scenarios.

Click here to download the 1.1 code.

Here’s a link to the project page.

Many thanks to Zac Spitzer who is responsible for writing the code to identify var statements within cfscript.  He completed the cfscript var statement support as a response to this post

After looking at Zac’s code, I decided to take it to the next level and complete the code required to identify variables created within cfscript blocks.

The code will even ignore variables created within comments, but unfortunately does not include the ability to identify the line number of the variable (which it does within tags).  You can still jump directly to the method, but you’re on your own to find the variable.

You can even identify variables created within for loops and if/else blocks.  Here’s an example…

for(correctLoop=1;correctLoop LTE 10; correctLoop=correctLoop+1) correctSimpleVar = correctLoop;

In this example correctLoop, and correctSimpleVar will both be identified with the tool.

For those of you who aren’t aware of varscoper, it is a code analyzer that will look for variables without a var statement that exist within a cffunction.  I released the tool last July and cfscript support has been the #1 request.

Additionally, I am now hosting the project at RIAforge at http://varscoper.riaforge.org/, you can look there for SVN access.

Please take a minute to test out the code and please let me know ASAP if you can find any cases that the cfscript code doesn’t cover.

From → varscoper

15 Comments
  1. David Buhler permalink

    That is undeniably one of the most useful tools I have tested in quite a long time. The timing for my current project couldn’t be better, too.

    My only suggestion so far (still need to use it more over the next couple of days) is to package the files up to a folder so they extract in a single directory.

    Much obliged,
    David Buhler

  2. Thanks for pointing that out David, I’ve updated the zip so all files extract to a folder named varscoper.

  3. David Buhler permalink

    Okay, I went through a few thousand lines of my current project’s code and made ‘several’ updates. :)

    Here are my suggestions:
    1) A success message when no unscoped variables are found. Right now, the result for "no unscoped variables" reads: Processed XX files and XXX cffunctions in XXms. I’d prefer: "Success: No unscoped variables found. Processed XX files and XXX cffunctions in XXms"

    2) For large scale projects, it would be a tremendous time saver to have an option that generated scoped variables one can copy from the varscoper output window, and then subsequently paste at the top of the function body. For example:

    <cfset var q_users = "" />
    <cfset var q_funds = "" />
    <cfset var q_bankingAccountInfo= "" />

    As it is, I had to copy and paste about a hundred results into notepad, remove the debug information, and then copy, paste, and format the scoped variables at the top of the function body. I’ll admit that there’s a danger in adding a default value and type like this, but it would have reduced my total work from 2 hours to about 20 minutes.

    Buhler

  4. This is very awesome news. Thanks go to you and Zac for getting cfscript parsing in place.

    You Rock!

    DW

  5. Woo-hoo! Thanks for the cfscript support. I’m sending this out to the whole team.

  6. Thanks for this new version Mike.
    I found some issues:

    1) CheckMimeType(mimetype_ID=qFile.mimetype_ID);

    varscoper will report "mimetype_ID" as unscoped

    2) stFile["#variables.sRelatedField#"] = variables.related_ID;

    varscoper will report "]" as unscoped

    3) // replace special characters
    sFileName = variables.oFileSystem.checkFileName(stUploadedFile.ClientFile);

    varscoper will report "replace special characters sFileName" as unscoped

    A possible solution for bug 3 would be a change in line 396 to:
    <cfset cfscriptArray[cfscriptIdx] = ReReplaceNoCase(cfscriptArray[cfscriptIdx],"//(.*?)\n","","all")>

  7. Harry-
    Thanks for the code, I’ll add them to the test case and get working on them as soon as I have some more free time.

    -Mike

  8. Big thanks Mike – a great tool and a valuable addition to any CF developers toolkit.

  9. Jamie Jackson permalink

    Great app, thanks! I’ve found one failing case so far: http://pastebin.com/f2e46ed29

    The highlighted line is a false positive.

  10. Jamie Jackson permalink

    Oh, one more thing. The teaser seems to be missing the word "don’t," as the second sentence doesn’t make sense:

    "If you have never missed a single (cfset var) statement when writing code, you can stop reading now. If you know what (cfset var) is for, then you absolutely need to take a look at this code.."

  11. Jamie Jackson permalink

    Whoops, just noticed I had to enable the cfscript support via a checkbox.

    Seems my case above does not fail with that applied. However, other (already reported) errors do show up now.

  12. Thanks Harry for your help with the bugs that were reported. Bugs are now fixed. I’ve committed the files to RIAForge and they are included in the zip as well. Keep sending the problem cases my way.

    Jamie, thanks for noticing the typo.

  13. One more bug. If you are using CFPROCPARAM and the variable =@myVar attribute but the type=IN it will report @myVar as un scoped.

  14. David Stockton permalink

    This is definitely a good tool to help double check your work.

    Thanks,
    David

  15. Kurt Bonnet permalink

    This utility rocks! Great work!

Comments are closed.