The Importance of Consistency

Fields. Layouts. Calculations. Relationships. All of these are invaluable pieces of FileMaker and we, as developers, implement our own flare, excitement, and style to each of them. And as a lover of the Liberal Arts I believe that we should always thrive to be excited about what we do and how we do it. But do you know what makes it a better experience? Consistency. I’ve learned this lesson the hard way.

• Flashback to the first database I ever built – I was so busy trying to understand and get things done that I forgot the magic of consistency.
• Flash forward to 3 years after I built that database – I now had a sticky mess in front of me. Every time I had to change a script or find a relationship, I struggled with what I called that field or how I named that script.
• Cut to now – While I still falter in consistency from time to time, I have learned the art of sticking to a style.

Here are some places where consistency can really help:

Fields

Choose a strict naming convention and stick to it! This is probably the predominant place for variation.

• Are you going to use spaces?
• Are you going to use underscores?
• How do you name your primary keys?
• How do you name your foreign keys?

With a recent development project where I needed to use SQL, I learned to avoid using an underscore at the beginning of fields (mainly for primary and foreign keys). Here’s an example of how I’d name fields:

• NameFirst
• NameLast
• AddressStreet
• AddressCity
• AddressState
• AddressZip
• DateBirth

So what do you notice about the field names above?

1. All fields that should be “grouped” begin with the same prefix. Most people wouldn’t say “name first” but from an alphabetical perspective, it helps to keep first name and last name together.
2. Camel case makes the field names easier to read
3. Above, I chose to avoid spaces but you could use underscores (e.g., “Name_First” and “Address_City” )

Layouts

Using consistency in layout names can eventually make for flexible scripts. For example, pick a suffix for layouts that are form view versus list view:

• Contact – Main
• Contact – List
• Project – Main
• Project – List

By being consistent, I could write a script that uses the Go To Layout step but instead of hard coding the layout name, I can use a calculation. Imagine that you are on the “Contact – Main” layout and you want to go to the list view. And you wanted a similar button for the “Project – Main” layout that took you to the corresponding list view.  You could write two scripts, or write one flexible script!

Here’s the calculation that would be used for the  Go To Layout script step:

Substitute ( Get( LayoutName ) ; "Main" ; "List" )

A calculation like that would work for either the Contact layouts or the Project layouts. Talk about flexible and easy!

Calculations

For calculations, I’ll focus on naming variables (whether in a script or in a Let function). The main goal for these is to be predictable. It’s never fun to hunt through a script to find what that variable name is. And as we know, since we have to always type in variable names (not select them like for fields), predictability means efficiency. Here are some examples of consistent variables I use:

• $count – Usually used in a looping script to tell me what iteration I’m on
• $total – If my looping script is based off of some stopping number, $total defines that number or stopping point
• $sp – Get( ScriptParameter ) in a script
• v – In a Let function, if I’m working with a field, I usually name a variable “v” for value so that I don’t have to keep referencing the long name of the field (or some other calculation)
• theList – Naming a variable “list” is not a good idea as there is a calculation that uses that word. Add a prefix to all “FileMaker words” – the, a, your initials, etc.

I’m by no means preaching the need to use my naming convention. I’m just alluding to the fact that I’ve “memorized” these values, which means that I won’t be surprised when I open a script and see a $count variable, for example. The purpose becomes very obvious to me (or at least obvious enough with some context clues).

Relationships

This, for me, is a place where consistency makes for MUCH faster development. If your naming convention is inconsistent, you spend more time searching for the name from a dropdown list, like in a Go To Related Record script step, than you do actually developing the database. Here’s my naming convention (which is not an uncommon one):

• Name your tables in either singular or plural form but stay consistent
• Name your relationships based on the path
• Use all caps for the Table Occurrence’s table name
• Use a double underscore in special cases (self joins, for example)

Here are some examples:

• PROJECT
• project_PROJECT__sameCustomer (a self join to show projects with the same customer)
• project_TASK (a relationship from Project to Task)
• project_INVOICE (a relationship from Project to Invoice)
• project_invoice_LINEITEM (a relationship from Project to Invoice to Line Item)
• project_invoice_lineitem_PRODUCT (a relationship from Project to Invoice to Line Item to Product)

The point to take home is not my methods, but the idea of having a method. The real problem comes when you open up a solution you started 6 months, 12 months, 24 months later and nothing “makes sense” because there’s no method to the madness.

What’s your method?