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 Fee doesn'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.

Comments

[Willem-Jan Kempen]

I have the same experience. I tried serveral naming conventions but they all made things complicater.

Thanks for your wonderful blog.

Kind regards

[Rob Russell]

I like the tip about the field comment.

How do you name your table occurrences?

Rob

[Tom Gelin]

Finally, someone who applies Occams Razor or KISS. Keep It Simple Sam. Naming conventions are definitely points of controversy. Personally I like upper CamelCase for Tables and lower camelCase for fields. TOG's use the anchor buoy method with the base or anchor seperated from the buoys by an underscore i.e Company_Staff_Task real easy to read. Company being the anchor Company_Staff being the 1st buoy related to Company and Company_Staff_Task being the 2nd buoy related to Company_Staff. Layouts should reference the table in some fashion, generally the table 1st follwed by the layout. My personal preference is to reference the table with all caps seperating the layout name from the table with a colon and space i.e COMPANY: Form, COMPANY: List, CLIENT: Form, CLIENT: List easy to read. Abbreviations can also work most abbreviations are easiest to read by leaving out vowels such as Cmpny for Company, Clnt for Client, Lst for List. At any rate I agrre with Mikhail KISS.

[Test]

Hi all!


Bye

[wio]

My suggestion is go to some programming course and learn programming basics

[Jeff Albro]

I like this as well... my only concern is wondering if having spaces in field names might come back and bite me later. Like what if I want to pull the data into a MySQL DB?

-Jeff

[m.edoshin]

2 Jeff. As far as I know most rumors about incompatibility with SQL or Web applications are urban legends. E.g. MySQL can handle data fields with spaces or other ‘special’ characters in them just fine, provided they're enclosed in ``, like `First Name`. FileMaker web publishing applies URL encoding to these characters, but it also has special functions to encode/decode URL-encoded text.

I know only one real case of incompatibility. There's a UPS application to calculate UPS shipping rates that cannot talk with FileMaker via ODBC if FileMaker fields names have spaces. To me it seems that this is a problem of the application rather than of FileMaker. There are several workarounds like using another integration scenario (there are more than one), or a separate “adapter” table with special field names.

[Olly]

Just came across this post. Interesting. Thanks Mikhail.

I prefix system fields with an "_" (still debating whether it useful) and suffix keys with _pk, _fk, etc (which i do find useful, esp in the relationship graph)

Like you I think natural naming makes the system feel cleaner and less complicated. A good example is a letter merge system where I use field names as merge placeholders (which users can edit).

I'm not totally sold as it's easier to identify (and select) 'CamelCase' in calculations & custom functions compared to 'Natural Named Fields' (with spaces).

As a side note, I've recently used Jonathan Stark's/Moyer Group Table Occurrence techniques*, I'm particularly loving the 'TableOne to TableTwo to TableThree" naming convention. I'm still tempted to add underscores in there mainly because of the FUD I've read in the past. Would be interested to here of any other actual incidents of 'spaces' breaking a system.

*More info on Jonathans site. http://jonathanstark.com/filemaker_development_methodologies.php

[Mikhail Edoshin]

Hi Olly. I think you're right saying that most rumors about spaces or non-letter symbols in field names are FUD. Look, FileMaker is sold in many countries in many languages; there are German, Dutch, Japanese, East European, Turkish and other versions. People there not only use spaces in field names, but diacritics and even hieroglyphs. I guess they don't meet much problems because of this and if they do, they somehow solve them. But we still read some advice that we should use only letters, numbers and underscores in field names because it's “safe”. I don't believe :) As I wrote above, I know only one real example of incompatibility because of spaces and it doesn't seem to be FileMaker's fault.

As for the convenience of selecting, I'd like to point out that we read code much more often than write, so it's more important to make it readable than to write faster. And CamelCase is less readable than plain text.

[jardimcamburi]

Os melhores apartamentos em Jardim Camburi estão a sua espera.
Temos as melhores opções de imóveis , preços e condições de financiamento.
Contato:
Tel 0xx27 3084-5709
corretorimoveisjc@gmail.com
corretorimoveisjc no gmail.com

Apartamentos de 3 quartos em Jardim Camburi
Apartamentos de 3 quartos com suíte em Jardim Camburi
Imóveis de 3 quartos em Jardim Camburi
Apartamento de 3 quartos em Jardim Camburi
Casa de 3 quartos em Jardim camburi
Cobertura de frente ao Mar em Jardim camburi.
Imoveis na Planta em Jardim Camburi