One thing that affects application performance, in your Legacy Code, could be a lack of (or misuse of) variable scoping. In our last post we discussed the usage of the various persistent scopes. Now, we'll talk about some of the other scopes that your application might be using.

In this post, we'll get the easy one's out of the way. It's really all in the name, for many of these, which I like to call the passalong variables.

- These are the variables from the url query string. Not the most secure way to pass around information, but some variables don't always require protection. It is typically good practice to <cfparam> url variables, on the off chance that the link was truncated.
view plain print about
2    param name="URL.debug" type="boolean" default=false;
- These variables are available to a template that is the target of a form post. It is made up of all of the form field names and values passed in a post, and includes a special "fieldnames" key as well, that contains a comma delimited list of all of the passed form fields. It is important to note that browsers do not pass checkbox fields that are unchecked, so it is always a good idea to <cfparam> any checkbox fields.
view plain print about
2    param name="FORM.categoryid" type="numeric" default=0;
- These are variables that are passed into a function method, for use within the function. When you need a variable in a function, from outside of that function (for instance, a persistent scope variable), you want to pass the variable into the function as an argument. This will help to prevent memory leaks, maintain encapsulation, and manage dependencies. A bonus is that you can use the argument definition in the method signature in a way similar to <cfparam>, by providing a default value.
view plain print about
3 * @access public
4 * @output false
5 * @returntype void
6 */

7function setUser (required string firstName, required string lastName, boolean isActive=true) {
8 // Your code goes here
It is always important to declare the argument's type in the method signature (as in <cfparam>), as it will assist in the overall security of your application by ensuring that methods receive the proper variable type.
- The attributes scope is the arguments scope of custom tags. Similar rules should apply, in that if you require data from another scope, within your custom tag, then best practice is to pass the variable in as an attribute of the tag. Just like <cfargument> and <cfparam> you can (and should) define a type for the variable, as well as a default value if necessary.

Quick author's note here: You'll notice, in my code examples, that I use the <cfscript> form of code, while referencing the <tag> form in my dialog. Most Legacy Code is tag based, but you will find more and more core business logic is written in scripted form. Each scripted block can be done in tag form, but I personally stay away from tag based code for anything other than view templates and any inline looping or conditionals of that view code.

In our next post we'll discuss the remaining scopes. These include some of the more tricky scopes used within CFCs and Custom Tags, as well as a few others.

This article is the eleventh in a series of articles on bringing life back to your legacy ColdFusion applications. Follow along in the Legacy Code category.