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.
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.