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.