FileMaker field naming conventions
I have been developing FileMaker applications for quite a long time (about 8 years) and have worked with different field naming conventions. Now I stick to the one I consider the best of all: natural field names.
I used to work, for example, with naming conventions that required me to name fields after their types (global, calculation), certain options (lookup) or roles (key). There were also standardized prefixes, so field names were quite cryptic like OopsThingAMaBobKeyGlob.
I hated this system. It wasn't difficult to understand and thinking up a name for a field was also very simple, because there was very little to think up, but in effect all the names looked same to me. I wasn't able to remember any of them and had to always pick them up from lists, which is a pain for a fast typist like me, especially when the typist is trying to write a complex FileMaker-4-5-6-style calculation.
I used to work with my own system too. I thought it would be fine to leverage the alphabet sorting as the only available field organization tool and designed a system with one-character prefixes to indicate field role. There were prefixes for data fields (d), derivative fields (e), interface-only fields (i), keys (k), script variables (s) and so on. A sample field name would be dName, eSum, iSaveButton, sCounter and so on. The field names were shorter, more readable, and easier to type — I almost never had to pick them from list and even if I had to, I was able to find a field in the list in seconds by typing first few characters of its name.
Unfortunately, the whole approach turned out to be wrong. Yes, automatic sorting is evil. When I sort fields manually, I express certain subtle relations between them: I usually group related fields together, and, for example, tend to put derived fields after source fields, and so on. As I said these relations are subtle, hard to formalize and often vary from table to table and from application to application. If I sort fields automatically, I'll lose all these tiny bits of information that help me to better control the development process.
When I understood this, the rest was straightforward. If I sort fields in what I think is their natural order, I should give them natural names as well. Yes! I should name first name as First Name, sum as Sum, options as Options. The only thing to consider when thinking up a name must be whether it clearly describes the thing and is easy to remember.
What are the advantages?
The more I use the system, the more advantages I see.
The code becomes far more readable making it easier to communicate with co-developers. A calculation like
Subtotal + State Tax + Local Tax + Delivery Fee + Tax on Delivery Feedoesn't require any additional comments, does it?Natural names help me to leverage certain FileMaker features with no additional effort. For example, if a field requires a value FileMaker shows a dialog like:
If you use natural names, you may not have to write your own custom message, because the automatic one can already be good enough.
Finally, sometimes it's good to expose field names to users. (I don't mean unlocking an application to users, though with new security options the idea starts making sense.) In one of projects I develop I had to give users a way to compose text templates with data placeholders and later, when a template is processed, replace these placeholders with actual data. For example, user needed to be able to write something like “this task was completed by <User Name>” and have it changed to “by John Doe” when the task was actually completed.
Initially I was going to add a table to store possible placeholders and then write a few functions to replace them in a piece of text. I did it actually. The system required two tables with several table occurrences, and a bunch of fields to display the possible choices, and a script to cache values in a global field, and a few custom functions to do the replacement. I think it was good experience, because at the end I realized I don't need all this stuff.
Most of the placeholders were simply field references and these fields were directly available in the context I needed to calculate them in. Immediately I refactored the whole piece. At the end I had a list of field names, and a very simple selector:
The Event::Created On is what it looks like: a field name. When it is inserted in a field, it gets << and >> at its sides and then a custom function goes through the text and evaluates everything between << and >>.
The whole module became much simpler, much more manageable and even more flexible and the key part to this were natural field names; I couldn't do this with cryptic geeky ones. By the way, can you guess where the description string below the field name comes from?
You're correct — this is a comment of the field.
Technorati tags: FileMaker, FileMaker 7, FileMaker 8.
