Naming conventions [was: Food Fight]

Dennis Brown see3d at writeme.com
Sat Jul 2 17:59:54 EDT 2005


Thank you all for your replies on your various style and naming  
conventions.  I have studied them all and have come up with a style I  
think will work for me.

I have started writing my personal style guide which I have appended  
below.  I have not included many of the good style suggestions of  
other's that I like yet, because I have been documenting the areas  
that are different from every one else's style.

I would appreciate anyone taking a look at what I am planning and  
comment if you see something else that I might want to take into  
consideration before I code it into stone ;-)

Dennis



My Personal Style Guide for Transcript Programming

Revolution Transcript has become my programming language of choice  
for my various projects.  These guidelines are designed to create a  
consistency of style in my scripts for my long term benefit in  
maintaining my code.  I will update this document as more issues  
become clear as needing formal structure.

I have chosen the postfix as opposed to the prefix tag scheme because  
I prefer to start my names as something pronounceable --with a silent  
tag.  It may not be applicable for all languages, but this style  
guide is specific to Transcript.  I also do not see the need for over  
specifying the variable types.


Naming Conventions for Variables, Constants, and Custom Properties

Appending the descriptive name with an identifier to determine its  
type and scope will aid in debugging and maintaining scripts.  It  
will also prevent a name used in a script from becoming a new keyword  
in a future release of the program.

Postfix  Meaning                        Examples             Comment

<num>G   Global variable or array       everyonesVar512G     Scope  
across stacks, use with caution*
W        Stack(window) global variable  myStackVarW          Scope  
across sub-stacks**
S        Script local variable          myScriptVarS         Scope  
across script
<num>    Local variable                 myVariable1          Scope  
inside handler
                                           x1,x2,y1,y2,z1,z2    use  
for x,y,z coordinates, or math
                                           i1,i2,i3,i4          use  
as loop indexes
                                           it,a1,b1,c1          use  
for intermediate math results

K        Constant                       myNumberK            Created  
with the constant command (RO)

P        Custom Property                myPropertyP           
Individual property of an object
P        Custom Property Set            myPropertySetP       Set of  
properties of an object (1d array)***


Notes:

Declare all globals at the top of the handler or top of the script if  
they are shared between handlers.
Declare locals at the top of the handler before executable statements.

Use variable names that are descriptive like "filePath1".  Names like  
"a1," "b1," which have no meaning should only be used for nameless  
intermediate results with a scope of less than a few lines --like the  
it variable would be used.

An ordinary variable can be converted into an array variable and back  
again with the split and combine commands, so a separate array  
designator is ambiguous.  Array variables are easy to spot because of  
their usual index: myArray1[index].

*Use globals sparingly. Code written with globals are sometimes  
difficult to debug since the globals can be changed anywhere. This  
means that if two stacks are loaded into the IDE at the same time,  
and both use a global called filePathG, and if either stack changes  
that variable, it is changed for both stacks.  This is great for  
adding new tools, but a nightmare for everything else.  Adding a  
unique number for each stack before the G will make globals with the  
same descriptive name unique between stacks.  There is also a  
registry of prefixes for global names that can be assigned individual  
developers or companies who write tools or otherwise might use  
globals for many users.  I think it would be just as unique placed  
anywhere (front, back, or middle) of the name.

**While this scope is not yet implemented, it should soon be out of  
necessity!  I will use this notation and declare all of these on a  
separate line so that a simple edit will change the scope after it is  
implemented:  global myStackVarW --fix

***My intention is to always use the array notation for accessing  
properties in sets.  I do not see any need to identify these  
differently than any other property because the context will show the  
difference.

Naming Conventions for Custom Handlers and Custom Functions

Capitalize the first character of a custom handler or function name  
to distinguish it from built-in commands and functions.  This will  
also help distinguish custom handlers and functions in the future if  
a new program release includes a new keyword or function that  
conflicts with yours.  I am considering if I should append something  
to the name to show where it is located --W,C,G for stack,card,group  
to make it easier to locate the scripts later.  Possibly F,B for  
front,back scripts also.

on mouseUp
    AddHandler 1,2
end mouseUp

on AddHandler param1,param2
    global resultW --fix
    put AddFunction(param1,param2) into resultW
end AddHandler

on AddFunction param1,param2
    return param1+param2
end AddFunction





More information about the use-livecode mailing list