That's really up to personal preference. My preference is to avoid using
direct "local." assignments. The only advantage I see to using the local
scope explicitly is that you can maintain the same variable name between
your arguments and local scope. However, you'd generally only need to do
that if you want to manipulate the content of the arguments variables
before using them while still maintaining that content in it's original
form.
Not sure I explained that well.... Take your function, for example. You
only make use of your arguments once in the SQL. If you were to assign
those to the local scope, the only thing you would accomplish is adding 2
lines of code with no actual advantage. Neither the local or arguments
scopes are accessible outside of the function, so functionally, they are
both in a local scope.
Now let's assume you want to do some basic sanitation of your arguments
before sending them to your database. Additionally, you want to write to a
log file tracking how much sanitation is being required based on user
inputs. In this case, you might want to put your arguments in a local
scope. For example:
<cfset local.domain = Trim(arguments.domain)>
<cflog file="sanitationLog" message="#Len(arguments.domain) -
Len(local.domain)# character difference for #local.domain#">
Again, this is only necessary if you want to maintain the same variable
name between both scopes AND you want to keep track of the before and after
values of your arguments. In the above example, if you didn't need to log
the character difference, you could just manipulate the arguments scope
directly:
<cfset arguments.domain = Trim(arguments.domain)>
Putting this all together, if you want to maintain consistent coding
patterns, there's 2 ways to approach this:
1. local scope all arguments and type "local." every time you want to
use a variable in a function (even for variables that were not arguments)
2. use different names in the local scope (using "var") when you want
to manipulate and keep track of original argument data. example:
<cfset var aDomain = Trim(arguments.domain)>
It's my opinion that option 2 ultimately yields less code and less code is
nearly always cleaner. In most cases, I have no need to know the original
values in my arguments variables, so I just manipulate the arguments scope
directly, so it's a lot less common that I have to create additional
variables inside of a function just for my arguments.
On a side note, speaking of input sanitation, there's something I should
have mentioned in my original reply. It's a good idea to get in the habit
of using the cfsqltype attribute in cfqueryparam tags. This adds another
layer of protection against SQL injection because CF will throw an error
before executing any SQL if the actual data type of the value doesn't match
the expected data type specified in in the cfsqltype attribute. As a
bonus, this ensures proper usage of single quotes in the SQL based on the
data type.
On Thursday, June 19, 2014 8:23:16 PM UTC-4, Jason Allen wrote:
>
> Another question
>
> I recall reading that in a cfc you should declare a local variable for
> each argument, set the local var equal to the argument, and then proceed to
> use the local var for the rest of your operations. Is that true?
>
> ie:
>
> <cfset var local = structNew()>
> <cfset local.userID = "#arguments.userID#">
>
> <cfif local.userID eq '1'>.......
>
--
--
online documentation: http://openbd.org/manual/
http://groups.google.com/group/openbd?hl=en
---
You received this message because you are subscribed to the Google Groups "Open
BlueDragon" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
