Naming Custom Properties

[Jim Ault]

On Apr 16, 2010, at 2:36 PM, Mark Swindell wrote:

> I always use gGlobalVar, vLocalVar, and cpCustomProp just so I know  
> what's what.  With these prefixes I never seem to have any conflict.
> Mark

I agree with Mark about prefixes to avoid reserved word conflicts +  
debugging at a later date

zGlobalStor - sorts to the bottom of Variable Watcher
xScriptLocalVar - sorts just above the globals
cpCustomPropElement
cpsPropertySet
arrMusicTrackInfo - array
aaaTempVarName - sort to the top of Variable Watcher for debugging

As an extra note on this fine Friday afternoon:

I name my fields and buttons with a suffix
fld nameFld, addressFld, modDateFld
btn goNextBtn
btn sortByIdBtn, putOutputOnClipbdBtn
-- and this helps in the Application Browser


Jim Ault
Las Vegas

On Apr 16, 2010, at 2:36 PM, Mark Swindell wrote:

> I always use gGlobalVar, vLocalVar, and cpCustomProp just so I know  
> what's what.  With these prefixes I never seem to have any conflict.
>
> Mark
>
> On Apr 16, 2010, at 2:19 PM, stephen barncard wrote:
>
>> In naming custom props and vars, I try to avoid anything that might  
>> 'look'
>> like any function or command name, not starting with a number, and  
>> using
>> underscore or dash instead of spaces.
>>
>> However array key names  ( myArray["text"] ) seem to be able to  
>> work against
>> some of these rules (as long as quotes are used).
>>
>> On 16 April 2010 10:24, Gregory Lypny <GREGORY.LYPNY at videotron.ca>  
>> wrote:
>>
>>> Hello everyone,
>>>
>>> I vaguely, very vaguely, recall that a custom property should have  
>>> a name
>>> that is different from the variable to which it is being set.  So,  
>>> for
>>> example, if myArray is the variable, then
>>>
>>>      set the myPropArray of this stack to myArray
>>>
>>> is fine, but
>>>
>>>      set the myArray of this stack to myArray
>>>
>>> does not set anything apparently.  I waisted a big chunk (no xTalk  
>>> pun
>>> intended) of time rediscovering that, and I'd just like to confirm  
>>> that that
>>> is the case.  I'm also wondering whether anyone can point me to  
>>> where this
>>> convention is discussed in the Users Guide or built-in dictionary.
>>>
>>> Regards,
>>>
>>>      Gregory