Protocol for naming variables in procedures


#1

For many years now, Jim has encouraged us to use variable names which are less likely to match those used in other procedures/databases so as to avoid conflict. An example he gave long ago was to begin local variable names with “lv”, globals with “gv” and so on.

Looking at the code snippets that are posted from time to time, it is apparent that lots of users consistently use exactly that protocol in all of their code. This of course becomes increasingly less useful - if everybody’s variable names have the same prefixes, the effect is the same as having no prefix.

When I want to make sure I’m avoiding all likelihood of conflict, I precede my variable names with a randomly chosen pair of characters, like cwNumber.

There is no charge for this advice.


#2

I’m pretty sure I never offered that example, and I don’t use a naming convention like that. (I know that at least one former ProVUE tech support employee did like that convention, so perhaps that’s where you heard it.)

For local and fileglobal variables, all you need to do is make sure that your variable names aren’t the same as a field name in the same database. One convention that I do usually follow is to name variables with an initial lower case letter, while field names are usually capitalized. So firstName is a variable, while FirstName is a field (though I wouldn’t advise using those two names in the same database, too close and might still cause confusion).

Anyway, with local, fileglobal and windowglobal variables, it doesn’t matter a whit if others use the same name as you, there is no possibility of conflict unless two of you are working on the same database.

For global variables, my first advice is to avoid them whenever possible – and it is almost always possible. If it is absolutely not possible, I would suggest using very long names that are unambiguous and very unlikely to be used anywhere else, for example globalAreaCodeDefault. My example is a poor one, however, as I suspect that a value of that name would probably be better off stored as a preference value.

Proper usage of global variables is so rare that I can’t think up a proper usage at the moment. Stick with locals, fileglobals, and sometimes windowglobals and you’ll generally not have to worry about name conflicts.