Naming conventions [was: Food Fight]

[Dennis Brown]

Thanks for the many replies about naming conventions.  So to summarize:

1.  The cryptic names are not really being pushed to make things  
unreadable, but as protection from the deficiencies of Rev.

2.  The lack of a naming scope somewhere between local and global  
(such as namespace or the method I suggested) has resulted in the  
burden being passed on to the programmer to come up with a hopefully  
(but not guaranteed) unique naming convention for globals that he  
wants to own exclusively.  Just putting a "g" in front of them is no  
better than not --because if everyone puts a "g" in front they are  
all in alignment again, but what the heck, I'm not going to be able  
to pronounce it anyway so I'll throw it in just so someone can  
understand why the name is ridiculously long.  You need to come up  
with something that does not look like an understandable name because  
that might seem like a good name to someone else also.  So if we want  
to use a global, we really need to have a registry of global prefixes  
so that a developer can claim a unique one.  For example I might want  
to use gSee3d<number><name>.  The number is so I can serialize my  
different projects (I will need my own private registry to keep track  
of those), and the name is what I want to call my global.  For  
instance gSee3D005FilePathToMyData.  Yes, I think I understand it now  
--where is the nearest restroom?

BTW: My current project (1 stack 1 card) has over 100 globals defined  
(many are large arrays) so that I can use a combination of created  
scripted groups of objects and common handlers where possible without  
needing to pass many arguments.  I have to do this awkward thing to  
make up for the slow speed of array processing and ironically to make  
my scripts maintainable.  Using names like these would cause my  
script lines to be very long an completely unreadable!  I use names  
like TF1,TB1 now instead of TriggerField1 and TriggerButton1.  I just  
define the abbreviations in the comments of the handler.  If my  
shortened names were gSee3D005FTF1, gSee3D005FTB1, I might have a  
hard time skimming the difference in the names causing more bugs.

I would not mind if the Rev IDE would allow me to do something like:  
set privateGlobals to "See3d005".  I will declare:  privateGlobal  
TB1,TF1, or possibly: privateGlobal "See3d005" TB1,TF1.  Then  
internally, the IDE can prepend the See3d005 to TB1, but in my  
scripts I only have to use TB1.  That should be trivial to implement  
and I could happily live with that.

3.  The reason for making local variables a bit ugly is to guarantee  
that they will not conflict with future keywords.  That is a  
reasonable consideration and bears further thought on the "nicest"  
way to do that.  Of course explicit variables is a good idea here.   
If you declare a local name, it should override when it makes sense  
as a variable name so future names will not break old stuff.  It is  
also highly likely that a handler for a missing capability might use  
the same name when a built in command is created in the future.

4.  The reason for making custom property names a bit ugly is to  
guarantee that they will not conflict with future built-in  
properties.  That is a reasonable consideration also and bears  
further thought on the "nicest" way to do that.

aWell bThis cIs dVery eInterresting.  fPerhaps gWe hCan iPropose  
jSomething kThat  lMakes mA nBit oMore pSense qBy rAddressing sThe  
tReal uIssues vBetween wWhat xUsers yNeed zTo aDo, bAnd cWhat  
dTranscript eNeeds fTo gDo.

I don't know about you, but my skimming speed is as slow as Rev array  
processing when I try to read the last sentence (and I just wrote it)!

Did I miss any important points?


On Jun 21, 2005, at 4:58 AM, Dave Cragg wrote:

>
> On 20 Jun 2005, at 21:06, Dennis Brown wrote:
>
>
>> Dar,
>>
>> Thank you for standing up for the rights (in a good natured way)  
>> of those who think it's overkill to have all these structured  
>> names in a conversational language with handlers that are usually  
>> only a few lines long.  Why mar the elegance of a understandable  
>> name with cryptic unpronounceable prefix letters all over the  
>> place?  It's not as if I wouldn't be able to instantly recognize  
>> ten years later what the local variable named partNumber in my 20  
>> line script was for, or even that it was a local.
>>
>
> I sympathise with your view. Although I use east-central-Hungarian- 
> semi-strict myself, I'd hate to see this stuff forced on anyone.
>
> But there are advantages that it's useful to know about. Others  
> have mentioned namespace clashes. Another advanatge relates to your  
> "ten years later" comment. xTalks have a large number of reserved  
> words in the form of commands, functions and properties, and over  
> time this number has grown. So a variable with a friendly name you  
> create now, may become a reserved word ten years from now. Those  
> who spend any time converting old Hypercard stacks probably know  
> how frustrating this can be. As an example, I recently converted  
> some Hypercard stacks that used the names "startframe" and  
> "endframe" as parameters in various message and function handlers.  
> I'm sure these seemed appropriate to the original author, but the  
> Rev compiler didn't like them. Rather than spend time thinking of  
> alternative available "natural" names, I just stuck a "p" in front  
> -- pStartframe, pEndframe. This quickly becomes a habit, so that   
> in no tTime, you gFind yourself taking sThis approach to pAll  
> variables.
>
> Cheers
> Dave
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>