Naming Objects, Handlers, ....

[sritcp]

I have gone through some of the earlier threads, mainly dealing with naming variables, not much about objects or handlers.

1. So far, I have used multiple-word (with intervening spaces) names for objects; e.g., "Master Table" (a datagrid), "Add Column" (a button), etc. Similarly, I have named DataGrid columns, e.g., "Last Name", "First Name", etc. This is so I don't have to set the object labels separately. Also, I am less likely to confuse these names with variables. I realized this may not be a good idea when I recently had to match these column names to the column names of an SQLite database table (I think SQLite Tables require single-word column names).

2. I prefix custom commands with a letter or two if they are in the card or stack script (and called from all over the program). This helps me distinguish (and locate) these commands and functions. I find this especially useful when a program contains a whole bunch of these commands called from within control scripts. I use names such as xsConvertCicksToScore, xcCullInvalidData, etc (the 'x' is to differentiate them from a script local variable or custom property).

My question is, is there a commonly accepted or recommended way of naming objects and handlers? Is single word the way to go?

Thanks,
Sri.

[Simon]

Here it is;
http://www.fourthworld.com/embassy/arti ... tml#Naming

But I do like the idea of c and s on custom properties.
Oh and yes, single word always. err... for me I mean Same with web stuff so you never have that %20.

Simon

[charms]

I decided to go with following naming concept:

First enable "Strict Compilation Mode" in "Livecode" -> "Preferences" -> "Script Editor"
When you start with Livecode it may be tempting to start without this but declaring variables becomes very important once you work with LiveCode for a certain time.

Method names:
As Livecode doesn't have a namespace concept I've decided to use following convention with dots:
* Short company two letter abbrevation: ee
* Name of stack or the grouping of the method: sql
* Camel case name of function: connect

Example:
function ee.sql.connect pDb, pUser, pPass
private function _ee.sql.lookupUser pUser

Variable Names are clearly defined:
* gVar = Global Variable
* sVar = Script Variable
* tVar = Local Variable

I usually don't use global variables. I define getters and setter methods as these can be executed from everywhere.

Here my old naming concept (was also a good one, the only thing I've changed are the method names with the dots):
http://carmstrong.net/?p=134

[sritcp]

Interesting.
Seems there is a wide variety of naming conventions people use.
My particular interest is in distinguishing a control from a handler from a variable from a property on sight (without having to think).
Going forward, I plan to use the following (most of it, I use already):

gGlobalVar
sScriptLocalVar
tTempVar
pParameter

cCustomProp

xHandlerName -- for handlers used within an object script - x denotes that it is a custom command, not a LiveCode built-in message (I can't keep straight the script editor's color coding scheme!)
xgHandlerName, xcHandlerName, xsHandlerName -- for handlers found in group, card, or stack script for use down the object hierarchy.

ObjectName -- single-word, camelCase, but the first letter capitalized, to distinguish them from vars and handlers.

Regards,
Sri.

[richmond62]

" declaring variables becomes very important once you work with LiveCode"

I've been working with Livecode for about 15 years, and not once have I declared a variable,

and, what is more, I am still alive to tell the tale.

[FourthWorld]

My habits are like Richmond's: I rarely declare variables, and almost never use Strict Compilation Mode. It's just a matter of taste; I know many who love that feature.

My own process finds me iteratively expanding and refining handlers so frequently that if I had to declare my vars as I go it'd double my work. I could declare them when I'm done, but when I'm done I'm done and move on to something else.

The engine does a great job of dynamically allocating variables. Strict Compilation Mode can be helpful to avoid collisions and typos, but for all the bugs my code has typos are rarely among them since I tend to copy-and-paste var names.

[jacque]

Ditto, I've been working with the language for 29 years, 15 or more in LiveCode, and have never turned on strict compilation. The main advantage that gets you is a spell check before compiling, and I rarely have that problem. The amount of extra script lines it adds to your code annoys me and, for me, removes the advantage of brevity that is one of LiveCode's best features.

It's a personal choice that some swear by, but it's not for me. If you make frequent spelling mistakes or use reserved words often by accident then it may help, though using one letter variable prefixes avoids the reserved word issue.

[jacque]

xgHandlerName, xcHandlerName, xsHandlerName -- for handlers found in group, card, or stack script for use down the object hierarchy

.

This could become a pain if you later find you need to move the location of the handler, you'd need to find all instances in the scripts and change those too.

[phaworth]

I realized this may not be a good idea when I recently had to match these column names to the column names of an SQLite database table (I think SQLite Tables require single-word column names).

Just a quick note that SQLite table and column names can contain spaces and other non alphanumeric characters. Still not a good idea to do that though since it means you have to enclose such table/column names in quotes every time you refer to them in an SQL statement.

As others have pointed out, Strict Compilation Mode is a very personal preference. I happen to be in the camp that feels very protected by it and willing to accept that it causes some extra coding lines. I stopped using it for quite a while because of the infamous "name shadows another variable" compile error that was happening way too often. I started using it again recently (the problem seems far less frequent now for some reason) and it's already flagged several typos in variable/parameter names including at least one where the variable name was simply wrong due to cut and pasting code from another script. But that's due to my lousy one-finger typing skills(?) and folks with good typing skills would doubtless not suffer from such problems.

Pete