Naming Conventions

[DanThomas]

Continuing the discussion from UI Automation and Lessons Learned:

@Joel_Rendall

I've seen your great advice in here and other forum posts and have been curious about your strategy for naming macros. It looks like you use a prefix that includes the app name plus the type of thing is controls? (UI)

Do you follow this naming structure as well as organizing them into folders by project?

For me, some subroutines can apply to several different projects I'm working on so seems like a better idea than what I do now (putting all routines and subroutines in same folder according to project).

If you've discussed your naming structure somewhere else maybe you've got a link?

Thanks for all your help!

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.

[JMichaelTX]

@DanThomas

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

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

[DanThomas]

@JMichaelTX

During development and testing of a macro, I do NOT delete the Variables used in the macro at the end of the macro.

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.