What we do at work, and what seems to work well, is to prefix all incoming
arguments with an underscore.
So for example <cfargument name="_username" required=true>
I always reference arguments by argument scope, so arguments._username
All new variables inside a function should be var'ed, names should be
descriptive and not easy to mix up.
I like to keep structs around to keep data contained, but it all depends on
what I'm working on.
If your functions are getting too long, you probably want to break it up
into separate functions and make calls to them, makes it easier to debug,
update, and get an overview of the code.
Btw, you don't have to use structNew() anymore, you can just do bla = {},
or declare variables like this bla = "#trim(something)#", you can just do
bla = trim(something).
On Wednesday, November 18, 2015 at 11:59:51 AM UTC-5, Jason Allen wrote:
>
> Yep, naming conventions were from me trying to simplify the problem and
> remove unneeded code.
>
> One approach I've used in the past for longer functions is to declare a
> struct named 'local' and assign all vars local to the function to this
> struct.
>
> <cfset var local = StructNew()>
> <cfset local.test = "#raguments.test#">
>
> Should I just do this for everything?
>
> On Wed, Nov 18, 2015 at 10:16 AM, Marcus F <[email protected]
> <javascript:>> wrote:
>
>> Here's how I understand it (I may be off, someone correct me if I am,
>> please).
>>
>> They are different scopes, but OpenBD traverses scopes to see if it can
>> access a variable for you, so when you set the testVar it checks the scopes
>> and sets arguments.testVar
>>
>> A co-worker tells me that if you var testVar, it would create a local
>> testVar variable that you can reference separately.
>>
>> Granted, you should never be using names that can be confused in this
>> way, but I assume it's just test code.
>>
>>
>> On Wednesday, November 18, 2015 at 10:52:04 AM UTC-5, Jason Allen wrote:
>>>
>>> This is what's confusing me.
>>>
>>> If you declare an argument, say 'test' and I pass it into the function,
>>> isn't it's value 'argument.test'?
>>>
>>> If I then declare a simple variable 'test', isn't a different variable
>>> than 'arguments.test'?
>>>
>>> Or, when declaring a function, do I not need to use the 'argument.'
>>> prefix to reference it?
>>>
>>> Basically, is 'arguments.test' the same as 'test'?
>>>
>>> If so, it's new to me. I thought they were different.
>>>
>>> On Wed, Nov 18, 2015 at 6:40 AM, Marcus F <[email protected]> wrote:
>>>
>>>> Because you're setting the variable to a blank value.
>>>>
>>>> The variable name is testVar, and you specifically set <cfset testVar
>>>> = ""> before checking the value.
>>>>
>>>> Name it something else and it'll work.
>>>>
>>>>
>>>> On Tuesday, November 17, 2015 at 6:33:12 PM UTC-5, Jason Allen wrote:
>>>>>
>>>>> *Hi Guys, *
>>>>>
>>>>> *I'm getting what I think is strange behavior. *
>>>>>
>>>>> *I'm building a function. *
>>>>>
>>>>> * <cffunction name="testFunction" returntype="struct" output="no"
>>>>> access="remote" returnformat="json">*
>>>>>
>>>>> * <cfargument name="testVar" type="numeric" required="false"
>>>>> default="" hint="" />*
>>>>> * <cfset var test=StructNew()>*
>>>>> * <cfset test.originalTest = "#arguments.testVar#">*
>>>>> * <cfset test.originalTestTrim = "#trim(arguments.testVar)#">*
>>>>> * <cfset test.testVar = "">*
>>>>> * <cfset testVar = "">*
>>>>> * <!--- test --->*
>>>>> * <cfif trim(arguments.testVar) eq ''>*
>>>>> * <cfset testVar = "woops">*
>>>>> * </cfif>*
>>>>>
>>>>> * <cfset test.testVar = "#testVar#">*
>>>>> * <cfsetting showdebugoutput="false" />*
>>>>>
>>>>> * <cfreturn test>*
>>>>>
>>>>> * </cffunction>*
>>>>>
>>>>>
>>>>> *The part I'm having trouble with is*
>>>>>
>>>>> *<cfif trim(arguments.testVar) eq ''>*
>>>>>
>>>>> *Even though I've supplied the argument 'arguments.testVar' and it is
>>>>> a recongized value (able to assign value to test.oroginalTest, *
>>>>> *the if statement is returning true and setting testVar to 'woops'. *
>>>>>
>>>>> *What am I missing? *
>>>>>
>>>> --
>>>> --
>>>> 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.
>>>>
>>>
>>> --
>> --
>> 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] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
--
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.
