I wish I could tell you that I have a finalized naming convention (I’m a professional developer, so you’d think I would), but I don’t. I can tell you some of the things I’ve done, though:
I got the idea of prefixes like “[KM]” from @JMichaelTX. I don’t use them all the time, but sometimes I find them useful, like the example I showed in the prior topic, like “[FCPX UI]”.
I generally use a suffix of “(Sub-Macro)” for macros that are not intended to be triggered directly, although I’m not doing this with the [FCPX UI] macros because the prefix pretty-much says that.
I use Groups mostly to be application-specific, because of the possibility of turning them into palettes. With that said, I usually use the suffix “Palette” when naming groups that are for palettes.
The one convention I am adamant about is variable naming. I always prefix variable names with a short string of lower-case letters that correlate to the macro containing them. For instance, a macro called “Reveal Macro Group” will have variable names like “rmgGroupName”, etc.
This allows me to look in the Properties/Variable Names dialog and determine where leftover variables came from. I try to make a habit of deleting variables when the macro is finished.
Also, I finally ended up agreeing with @JMichaelTX that the use of the prefix “DND__” for variables that shouldn’t be deleted (DND = Do Not Delete) is a good idea.
Other people have other ideas. I’m sure they’ll jump in.
I totally agree with Dan on using variable prefixes.
We have a minor difference on naming convention, which is pure style, pure preference.
I prefer a prefix of uppercase followed by two underscores.
So, Dan’s example of “rmgGroupName” would be:
"RMG__GroupName"
The reasons I like this prefix naming convention are:
Easier to spot in the KM Variable list
When used in a “Prompt for User Input”, the prefix is NOT shown, providing a more user-friendly display.
Choose whichever you prefer, or make up your own.
During development and testing of a macro, I do NOT delete the Variables used in the macro at the end of the macro.
This allows me to use the KM Variable list for debugging.
When I am finished, I add a block at the bottom of the macro to delete all Variables used (except for those that begin with “DND_”.
I use a script that deletes all variables with a given prefix.
I agree with everything else Dan said about naming conventions.
One thing I may add is:
Do make good use of naming conventions
Choose conventions that are intuitive for you, but also would make sense to others
Another time I don’t delete variables is if I cancel a macro early, either due to clicking the “Cancel” button on a prompt, or because of an error. Of course, since KM doesn’t have the concept of a “try/finally”, it would be hard to delete the variables anyway, but allowing the variables to remain sometimes helps diagnose errors.