Not to disagree with Cody but just to clarify:
"and then later see *ANY* variable that is not prefixed with your
struct name (I use "local") then you know you have a bad variable.
"
This of course only applies to variables that should be local to the
function. By "local to the function", we mean that the variable should
only exist for the duration of the execution of the function. You might
also use the variables scope within a function to make that
variable available to other functions in the CFC. Or you might set
variables to session scope for instance within a function ...
in either case you wouldn't have a bad variable there. :)
The reason there's all this hullabaloo about var scoping local
variables is because if you don't, they wind up in the variables
scope by default. A lot of times, that doesn't make any difference. But
once you start persisting your CFC, say in the application scope, eg
<cfset application.myCFC = CreateObject("component","myCFC") />
those variables that you've created locally hang around in the
instance. Now, sometimes you want that, but then to be clear in your
code, it's recommended to scope them using variables.myVariable.
If you forget to scope your local variables, and you persist the
CFC, and that variable hangs around, it sometimes causes very difficult
bugs. So that's led folks like Cody and me into condemning such
unscoped variables as bad. And the reason we get all pedantic
about it, saying you should always var scope your local
variables, is because even if today it looks like it won't cause a
problem, you never know what changes you may make to your code later
that will suddenly make a stray persistent variable into a bug you have
a very hard time finding.
Just wanted to make sure that was clear.
ciao,
nando
Cody Caughlan wrote:
I find it
help to just var one struct and then put all local variables inside
that one struct. If you follow this procedure and then later see *ANY*
variable that is not prefixed with your struct name (I use "local")
then you know you have a bad variable.
Example:
<cfset var local = structNew()>
<cfloop from="1" to="10" index="local.i">...</cfloop>
<cfquery name="local.qryName">...</cfquery>
<cfset data = "" <!--- BAD!! Not prefixed with
"local." ---->
In some of my bigger functions where I am using 10-15 local variables,
it gets to be a maintenance nightmare to double-check that I var'ed
everything. You can save yourself a ton of headache and just use this
approach.
/Cody
Brian Peddle wrote:
Thanks Everyone that was my next question
index="x" ...
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf
Of Anthony Israel-Davis
Sent: Friday, July 21, 2006 1:59 PM
To: [email protected]
Subject: RE: [CFCDev] Scoping Question
Yep - most definitely. As well as any iterator variables in loops (e.g.
index="i" would need var i = ""), return variables from cffile or
cfhttp
- basically anything that needs to remain function local.
These got me when I first started in on this - particularly the cfquery
one!
anthony
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf Of Brian Peddle
Sent: Friday, July 21, 2006 10:54 AM
To: [email protected]
Subject: [CFCDev] Scoping Question
I am pretty positive this needs to be scoped but want to verify
Example CFC to return query results:
<cffunction name="getSearchOptions" access="public" output="no"
returntype="query">
<cfset var resultset = "" />
<cfquery name="resultset" >
Query here
</cfquery>
<cfreturn resultset />
</cffunction>
The resultset should be scoped right?
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject
of
the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject
of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject
of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject
of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
|
