Am thinking of prepending an accented letter to my named Rules/Edicts/Stamps/Agents/Prototypes, as in - ṕPrototype, ŕRule, éEdict, áAgent, and śStamp. As I write and capture text almost exclusively in English, the visual distinction would work well for me.
This will entail some mass-renaming, so I thought to poll the user group for possible breaks/pitfalls in adopting this method. Thoughts?
This use of a prefix to indicate the type of an object is called “Hungarian Notation” after its most notable advocate, Charles Simonyi.
I’m not a big fan. If you’re looking at a stamp, for example, you know it’s a stamp. If you’re looking at an agent, you can see it’s an agent. The prefix doesn’t really add very much.
Then again, I believe that I argued in the opposite direction in The Tinderbox Way.
Good advice. I think it’s mainly to speed search results, as I can disregard certain Notes.
Am also thinking about a quick method to filter and pluck out newly created Stamps/Rules/Edicts etc by placing them in dedicated Notes - these dedicated Notes would then go into my Agents/Prototypes/Rules/Edicts/Stamps Library project, for later re-distribution among other projects.
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 Test and 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.
Yes to all these points!
I really need to habituate creating more functions. I’ll get into it shortly, I hope.
Yes - adding the accent is an additional step, but infinitesimal when compared to the effort that designing an Agent or Stamp takes me 
I also appreciate being able to return to a project weeks/months later, and immediately identify transportable elements (as opposed to project data).
I figure that accents will always be factored in to any forms of Unicode in years to come, and the ácute is pretty universal.
Curious on how the accent will benefit you, what this the practical difference between ṕNote and pNote?
Primarily rapid visual reassurance, as I skim down a list of 100 Notes. Suits how my brain works; and also easier to search and segregate ‘active’ Notes from the rest.
Another case I did miss is variable naming. If I declare a variable “Person” in a some complex code making a report and further down (the variable declaration now scrolled offscreen). Now if I ad code:
$SomeAtribute = "Person";
Am I setting a literal string value, a prototype name, a stamp, a function (OK, that needs always needs trailing brackets - yet action code operators don’t), or a variable.
This use —when I need to—these prefixes:
Other choices are available, but I hope that rounds out the point.
With attributes if the data type is no obvious I may append a type to the name: e.g. PersonList might make more sense which typing action code than Persons or People. Or, we could use $Account for a person’s account number, but if (due to a system we can’t alter) the 'number’s are values like ‘v1234’ we can’t store the ‘account number’ as a Number-type. So, as a hint to future self AccountString might be helpful. I worry less about the aesthetics of naming than clarity of purpose, especially to help future self months or years later. Even if only writing for our own private use, what is ‘obvious’ recedes with time.
A further stylistic ‘tic’ for me is avoiding one-word user attribute names. So $PersonList not $People. Why? Never say ‘never’, but I don’t make notes with CamelCase names so if I do mess up and unwittingly force Tinderbox to guess, it won’t match a literal string where i intended an attribute name.
As already discussed, how exactly we name things—in terms of what prefix to use—is very personal but the underlying rubrics of why/when we might prefix do hold.
Very important point, especially when one is returning to projects after an absence. The non-obvious path Applies not only to Tbx, but all project work I think.