The differences between identifiers, keywords and reserved words
Even though the IDE paints them all the same color, they're not the same in the way you can use them in code code:
- Identifiers are words you can use to name your methods, properties, variables etc.
- Reserved Words (or reserved names) are all those that you can never use as identifiers. This includes: if, then, to, function, end, attribute
- Keywords are a mix of the above. They are all those words that are pre-defined by the compiler. This not only includes the Reserved Words but also standard types such as String, Integer, Boolean and Color. But it does not include Date, for instance - that's a name from the framework, i.e. it's practically code written in Xojo that you do not see but that the compiler secretly adds to your source code when building your program. You can tell the difference if you use XojoScript (RbScript), which is a bare bones access to the compiler without most of the framework: While you can use Color there, the Date class is not available. (Note, however, that even XojoScript gives you a small framework to work with that includes some strings operations and the Print function, for instance).
Now, here's the interesting part:
Whereas you cannot declare a variable with the name attribute, you can declare one with the name boolean!
Here is an example that actually works:
dim boolean as integer boolean = 2 MsgBox "The value of the variable 'boolean' is "+Str(boolean)While the above is quite some nonsense, it can be used in other ways, too, for instance in an enumeration. You can declare an Enum named Types and add the values String, Integer, Boolean to it. Then you can write:
dim t as Types t = Types.IntegerBTW, for that very reason that reserved words (if, then etc.) are not the same as predefined types (String, Integer etc.), I tend to write the former always in lower case while I write types (both predefined and self-declared ones) always in upper case. So, while some may think my mixed case code writing is inconsistent, it actually follows rules based on the understanding of the language.
I often see beginners not making best use of Boolean types.
if found = True thencould also be written as:
if (not (found <> true)) <> false thenThe second example is clearly unreadable and therefore quite counterproductive. The first one is, to some lesser extent, similar in that nature.
The recommended variant would be:
if found thenRead it aloud. Doesn't that sound better than the first example?
In the same way,
if found = False thenshould be written as:
if not found then
Think about this the next time when you choose a name for a Boolean property or variable. Name it so that it reads well in a "if ... then" sentence, avoiding "= false" and "= true" constructs. It clutters your code and makes it often less readable.
Similarly, you may want to avoid constructs like these:
if me.Value = true then button1.Enabled = true else button1.Enabled = false endWhy not simply:
// enable button1 only if this checkbox is checked button1.Enabled = me.ValueThough, some may argue that "me.Value" is not self-explanatory, thus "me.Value = true" is adding some context. Here's an alternative that's even more self-explanatory:
dim checked as Boolean = me.Value if checked then
dim checkboxChecked as Boolean = me.Value button1.Enabled = checkboxChecked