Although I tend not to bother for simple documents, I often use prefixes for prototypes, export templates. Now stamps are notes I’m tempted to do the same.
The original reasons were pragmatic and dealt with two issues:
Name collision. This is most easily explained by a quick demo. In a new tex, make two notes called
Person. Then add the built-in prototype “Person”. Now write a stamp with the code
$Prototype="Person" and stamp note
Test. Most likely it will change to look like the desired prototype. But, the document has two notes called ‘Person’ and when Tinderbox finds two or more notes when it expects one, it use the one with the lowest $OutlineOrder value and the note is before the same-named prototype. Tinderbox in this case is savvy enough to know the first match is not a prototype. But, as in a recent report to support, when setting a prototype by $Name in more complex action code, the app guesses wrongly. Of course if you have a prototype called 'pPerson" or “ṕPerson” then a naming collision can’t occur—unless you’ve a habit of writing normal notes with such prefixes. But for any individual user having a chosen a prefix wisely, name collision in this context is unlikely.
Using Name vs path addressing (name coalition redux). When using references to another note in action or export code, you can cite the $Path or just the $Name. Now, in a file like Tinderbox, it turns out my templates were often not unique. I could type the full path ($Path value) but that makes for verbose hard to read templates. So, I give the templates a prefix to their $Name to avoid the name collision, and have shorter, more readable code.
Understanding purpose (what you’re called is what you are). This really only affects those who go deeper into action code use. You only need, once, to define a function with name that looks like it could be an action code operator and make a code error and end up (later on) wondering if you’ve mis-typed the name of an action code or you’ve called a user function. So I tend to use a prefix on my function names: I use an ‘f’ but it’s not a rule—other characters choices are available!
Don’t be tempted to say “but I’d never be dumb enough to make this mistake”. We all make mistakes. We may recall code we wrote earlier that day but, six months on, the Blessed Sponge of Amnesia may have wiped away that knowledge. So, setting yourself up to not fail can be seen as enlightened self-interest. But, these sorts of strategies are highly personal. Some hate them because they think prefixes make things “look ugly” whilst even amongst those who do re-name, their chosen character(s) for prefix—or suffix—on special notes will vary. It’s a an individual choice, not a rule. I don’t normally prefix stamp names but if making stamps to be called in action code, I might do so. That said, now we have functions, such stamp I’d more likely write as functions than stamp, to the same outcome.
I probably write as much code/configure TBXs for teaching others as I do myself. Plus, in aTbRef i’m invariably needing a note to be named after what is describes, which is also a term the app uses, so such suffices help. In the same way, in examples if use attributes like $ExtraList so the reader knows I’m using a List-type and doesn’t have to look in the Inspector to find the type. But again, that is not a rule, but more of a guard-rail for the learner or the forgetful. Once a user gets comfortable with the parts of the app they will see they can colour outside the lines if it better suits their purpose.
I raised an eyebrow when I saw the accented characters as they take extra effort to type. But as said above, use what makes sense for you. I’d avoid anything truly exotic, e.g. some funky symbol found in the depths of the Unicode character viewer. I’d never escape the feeling that one day, and an inconvenient moment, that character had a purpose I’d not envisaged. Remember, we’re (re-)naming to either/both avoid name collisions or to indicate purpose.