Nando-
Yes, you're correct. I should have made that clear myself. Thanks for pointing it out!
/Cody
On Sat Jul 22 12:56 , Nando sent:
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
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:
...
...
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:
returntype="query">
Query here
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]
----------------------------------------------------------
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]
