Attribute names, whatever their type, are:
- Case-sensitive. 'pronoun', 'ProNoun', 'Pronoun', 'PRONOUN' are all valid names that if created would be 4 discrete attributes.
- The first character must be a letter (upper or lower case) from the Roman alphabet, i.e. A to Z. It must not be a number or an underscore. From v9.1.0, the initial letter can be accented (bearing in mind that at a computer code level, accented letters are a different character) and may be a non-roman script character.
- The name must include at least one character (see further below for why single-character named attributes are not generally a good idea).
- Until v6 only Roman letters and numerals, plus the underscore character, were permitted in attribute names. So, the allowed characters are:
- capital A to Z (including accented characters), including non-Roman scripts (from v9.1.0).
- lowercase a to z (including accented characters), including non-Roman scripts (from v9.1.0).
- numerals 0 to 9 (not recommended - see below)
- underscore
- Post v9.1.0, non-Roman alphabet Unicode characters may be used for all except the first character. This can include characters from double-byte languages, but right-to-left oriented languages (e.h. Hebrew, Arabic) should be avoided; in both these cases check carefully before committing to extensive use.
The Document Inspector's User tab for making new user attributes will suppress keyboard input for any other characters to help enforce this rule. So you may have 'ToDo' but not 'To-Do', or To Do' as an attribute name. A name of '8' or '009' is not allowed. When typing a new attribute name in the Inspector, or changing an existing one, unsupported characters (in the position as typed) appear in red. The attribute's name cannot be saved if any red characters are showing.
When importing spreadsheet type data tables and new attribute names are coerced from column names, an underscore will be used to replace any unsupported characters (e.g. accented characters).
Take great care when importing data with numerical column heads, e.g. '2' or '37'. If the attribute names and default value (likely zero) differ this can confuse Tinderbox's legacy support in code parsing. Thus id attribute '2' has a default value of zero, $SomeNumber + 2 may be misinterpreted as $SomeNumber + $2, i.e. $SomeNumber + 0, and thus no change. Of if the $2 in context has a value of '10' then the code might parse as $SomeNumber + 10. so not as expected. So, number-only attribute names are allowed, but liable to cause problems so are an ill-advised choice unless circumstances dictates so.
User Attributes: suggested naming style
Although you may use any letter case combination it is worth noting that the general style in Tinderbox, and examples in the manual etc., tend to one of two styles opening capital ('Prototype') or inter-capitalised ('AgentPriority'). For newer users, adopting the latter form for user attributes will help to distinguish attributes when seen in action and export code - see more on suggested naming.
Perhaps self-evident, but adopting self explanatory names is useful both in writing codes but also when displaying Displayed Attributes. Also make use of the attribute's Description box, to describe the attribute's purpose (do not rely on your memory some years later).
Further naming considerations
User Attributes can be renamed (but not system attributes).
Single character names (i.e. single letter - see list above) are allowed though are impractical and not recommended. Such brevity is likely to cause error at some point.
NOTE re Attribute names & the $-prefix. In action code, when an attribute's value is referred to a $-prefix is used. Thus to call the value if the attribute WordCount, $WordCount is used. To refer to the name of said attribute, use "WordCount". Within aTbRef, inline references in general text which refer to Tinderbox attributes names generally use a $-prefix as a marker that it is an attribute name being cited. The latter is a slight variance with in-app usage but does aid clarity in the articles.