Naming Conventions

Continuing the discussion from UI Automation and Lessons Learned:

Thanks for the kind comments.

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:

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

Good point, and something I also do.

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.