http://coldfusion.com logo
Join Slack
Powered by
what I'd imagine is a fairly straight forward ques...
# cfml-general
a
what I'd imagine is a fairly straight forward question. If I 2 variables defined with the same name at different scopes. 
VARIABLES.foo
and 
var foo
within a function (which I think is the equivalent of 
LOCAL.foo
?) and within that function I assign foo a value using 
foo = 'test'
would I be correct in thinking it'd use the local variable ?
t
t
The section called "evaluating unscoped variables" lists the order of precedence.
a
"when you tried it, what happened?"
@thisOldDave I would be very cautious of testing things to do with scopes on trycf.com. Abram monkeys with the code before it runs, and I think it's run in the context of a CFC method, so not exactly representative of how a stand-alone CFML script is usually run.
j
Ideally, you should be fully scoping your variables to avoid exactly this kind of confusion in the first place. The habit really pays off on bigger projects/multiple devs/when you revisit your code.
j
^^Exactly
a
On the other hand: I think ubiquitous scoping adds clutter, and only specify them when it needs to be made clear (eg: using a variables-scope variable in a function for example). If you have small functions (which you should) and tests (which you should), accidental referencing variables in the wrong scope kinda stop being an issue, and yer code is cleaner for not having the clutter.
But; to each their own. Our current coding standard says "scope yer variables", so that's what I do.
s
@Adam Cameron where do the arguments go? like if you just say [var]
Back in the day the rule was scope them i.e. var.foo
now it seems that the efficiency win is so minimal that for readability / maintenance just say the var name
s
My rule was don't scope arguments or local vars but scope everything else (especially variables scope).
a
Yeah on reflection in the context of CFC code (which is where all our code ought to be these days, yeah?), @seancorfield's nailed it better than I did. The only scopes one would be accessing on a regular basis in our code would be 
this
, 
variables
, 
arguments
and 
local
. One needs to actively quality 
this
, I seem to recall. One's framework should internally deal with 
form
/ 
URL
/ 
CGI
/ 
cookie
etc - stuff coming in that represents a request - so there should be no need to ever references those. There is no need to use the 
request
scope. 
application
-scope / 
server
-scope / 
session
-scope should only be referenced in application lifecycle methods: being passed into objects that have their own local references to them (eg: via DI). Off the top of my head I dunno enough about scopes used in threads and other miscellany, but I would only scope those 1) if one actually needs to; 2) to disambiguate from the context-specific local scope.
@salted no need to scope arguments. It's not possible to have a local var shadow them anyhow, and they're second in the scope-look-up after local scope anyhow. One's functions should not be so long one loses the cognitive context of where the variable came from, as the function signature should be on the screen (ie: not scrolled off the screen cos the method is so long it needs to be), anyhow. I think needing to scope stuff so one can keep track of where variables came from us indicative of code that needs refactoring, now that I think about it.
a
Thanks all. I think it's best to avoid using duplicate variable names where possible anyway
j
also need to be cognizant of which local scope you are actively dealing with, for example, using a member function like .each( func() )/.map( func() ) etc, withing a cfc function, the local scope is within that func() argument, where as if you need to access cfc function local variables around it, you must omit the local scope (which gets my "scope everything" twitch going). You may also not have access to cfc variables scope iirc, and need to copy it down to cfc function local for the func() to be able to interact with it
3 Views
Open in Slack
PreviousNext
Powered by