Having FileMaker Naming Conventions and Standards is especially important when working in a team environment. You will find applications easier to maintain and developer-friendly. The solution will be self-documented by the metadata of your development standard.

The recommendations below are based on our naming conventions and standards from our years of experience and are the foundation of all of our solutions. What is really important, no matter what development naming convention and standards you choose, is that you be consistent throughout your FileMaker Pro application and document your naming conventions and development standards.

This standard is by no means how you must develop your FileMaker Pro solutions. We continuously evolve our naming conventions over time as FileMaker introduces new features and capabilities. You are at your own discretion as how you build and develop your Filemaker application. We hope to provide you with valuable insight into how we develop consistency in our FileMaker Pro projects.

1. Relationship Graph - Table Occurrence Naming Convention and Standards

This is the most important naming convention for FileMaker Developers. Determining your standard for the relationship graph that focuses on readability is critical as FileMaker is context-driven. The goal should be that you never feel the need to print out the relationship graph. Many times developers create their FileMaker table occurrence names without a naming convention in the relationship graph. The FileMaker relationship graph provides great flexibility, the more rope the more you can hang yourself.

The first thing we do is follow an anchor buoy naming convention that avoids relating base table occurrences to each other as you may create an inter-tangled web that is difficult to maintain when developing over time. Our methodology will NEVER connect one base table to another to ensure readability as the solution grows over time. We also always CAPITALIZE all table names. You will see why below.

The anchor buoy methodology we use ensures each relationship is created from the context of the base table and the base tables are never connected to each other. The relationships connected to the base table begin with the prefix of the base table (ie contact__ORDERS__contactID__del_cre). The table occurrence is assigned to is designated in ALL CAPS (ie contact__ORDERS__contactID__del_cre) in the table occurrence name. The suffix includes any optional parameters being used in the relationship, cascade delete, ability to create related records via the relation, and sort if present in the relationship (ie contact__ORDERS__contactID__srt_del_cre).

Many times relationships are only one relationship/table away, but as solutions become more complex and benefit from good relational design the relationships may go 3+ relations away, thus the anchor buoy methodology is used from the base table. This could be Contacts->Orders->Line Items. The syntax for 3 or more table occurrences is below.

<starting-from-tablename-lowercase>__ <next-to-tablename>__ <DESTINATION_TO_TABLENAME>__ {<optional_descriptor>}_ {<del>_<cre>_<srt>}

Terms in braces optional, based on perspective and usage. Example: contacts__orders__LINE_ITEMS__del_cre_srt

Relationships back to the same table are documented as SELF relationships and the destination table name is called SELF <starting_from_tablename_lowercase>__SELF__<description_lower_case>> {_<del>_<cre>_<srt>}.

The main purpose of this technique is to never connect one base table to another as this will relate all tables over time and create complexity when looking at related relationships with ongoing development and maintenance. The downside of this hybrid relationship convention is many times you create the same relationship in another base table to replicate the same functionality in different contexts, but the upside to us is lower long-term development costs with the simplicity of having good metadata in the table occurrence/relationship names.

2. Field Naming Convention

Lower Camel Case Naming Convention

The use of lower Camel Case naming convention is our preferred method. This is the practice of writing compound words or phrases without the use of spaces and each word is capitalized. (eg. iMac, ). This convention helps maintain SQL compatibility, avoids the usage of spaces in field names, and keeps field lengths to a minimum character level.

Keys

All key fields begin with an underscore, followed by ' k' for key, then the type of field is designated (ie. __kpn and _kfn). Proper field naming will provide self-documentation, also known as metadata (data about the data), and be very resourceful as the field name itself contains information about the field to the team/developer when referencing.

Starting the field name with an underscore also is a benefit when fields are sorted alphabetically (which they are by default in the relationship graph). The key fields appear at the top.

NOTE: In .fp5 fields beginning with an underscore character sorted alphabetically would appear at the bottom, in .fp7 data is now sorted via UNICODE instead of ASCII in .fp5.

Naming Key fields, types of keys (Metadata)

__kpnID - primary key (should be in every table)
_kfnOrderID - foreign key (one or more likely in many tables)
_kctDescription - compound key (combination of fields)

Derived Data (non-user-editable)- Calculations, Summary, Global Fields

Naming derived data fields creates metadata on the field level. We always start derived data fields and non-record level data (globals) with the letter 'z'. This self documents the type of field and also sorts to the bottom of the list alphabetically by field name.

The order of fields when sorted alphabetically will be key fields, user fields, and then derived fields and non-record level fields. ie (calculations, globals, summary). A great benefit of this naming convention is when working on the solution the field name provides metadata to the developer as to what type of field they are working with. A field starting with 'zct' means the field is a calculated text field, etc.

1st Character of Non-User-Editable Fields

z - All non-user-editable fields start with the letter "z" to ensure they sort to the bottom of the list of fields when sorted alphabetically. This is the first character of all non-user-editable fields. (we name the field zip code, postalCode or addrZipCode to avoid the common zip code field being in the list of z fields).

2nd Character of Non-User-Editable Fields

g - global field (used as a prefix for all global fields, data used for all records in the table) c,s - calculation, summary fields (used as a prefix for calculation or summary fields, ie zc, zs).

3rd Character of Non-User-Editable Fields

t, n, d, c, i, m - text, number, date, container, time, timestamp (used for NON-user-editable fields only currently, ie zgtMyGlobalTextField, zcnMyGlobalNumberField, zcdMyCalculatedDateField, etc).

Examples of Naming NON-USER-Editable Fields

zcnTotal zgtUserLogin zsTotalInvoices

Housekeeping Fields

Include in every table Creation date, times, timestamp's (at minimum include timestamp) Modification date, times, timestamp's (at minimum include timestamp) Creator/modifier names creationDate, creationTime, creationTStamp modDate, modTime, modTStamp creatorName, modName

3. Layouts

Context

Your standard for relationships and table occurrence will drive the standard you chose with layout names and their table occurrences they are assigned to. We like to attach layouts to their base tables. This easily allows the understanding of the context of the layout to the developer. In addition, this allows for the organization of layouts based on the context of the table very easily.

Layouts and the Separation Model

In many cases, solutions are broken up into many files ranging from 2 to 6, in most cases when properly consolidating files. Depending on the development model and methodology the data being stored you may have a solution with an interface only file, a data only file, a business logic file, or separating files by their module like a file for photos, a file for calendaring, etc.

This topic was added so you understand that you can separate the interface from the data files or choose to build the interface and data within the same file. We utilize separation on an as needed basis.

4. Scripts

Commenting Scripts

Scripts need to be commented at all times. Each should begin with a PURPOSE: at the top then the details follow including when the script was last modified and by whom including the variables used and their purpose. Commenting your scripts is very important when working in a team environment. The more complex the more comments are needed. A sample of commenting we use is below.

#PURPOSE: To show you a commented script example
#2014-11-21, KH, created script
#
#Variables
# $scriptParam - stores the script parameter, which is a list of parameters
# $recID - primary key of the record finding
#
#Setting Variables
Set Variable [$scriptParam ; Get(ScriptParameter)
#
# Finding Record
........(more stuff would be here but that's enough to understand)
#
# Terminating Script
Go to Layout [original layout]
Exit Script []

Terminating Scripts - Exit Script [$scriptResult Optional]

All scripts should include an Exit Script call at the end of the script

1. When debugging scripts you ensure that you can see the last result of any script step. For example, if you set a field as the last step, this value is not easily seen as this is the last script step in debugging. By having an additional step of Exit Script, you will see the last result of the last action taken in the data viewer while debugging a script.

2. In addition if you are returning a parameter that may hold one or more values this can be done in the Exit Script calculation. This provides the parent script the ability to return a Script Result value for usage.

Navigation

All navigation should be scripted and the use of Go to Layout on a button avoided. This provides many advantages, future navigation changes only need to take place in a single script vs changing many buttons on many layouts. In addition when referencing DDR's the layout will clearly be shown as being used which prevents accidentally deletion.

Summary

There are many different approaches to how you develop your FileMaker solutions. This guideline is an example of our guidelines to maintain a developer friendly solution in a team environment. Implementing naming convention and standards provides a foundation for team environments. We try to keep solutions simple enough to maintain and understand for all parties. We hope you find some of the techniques valuable for your FileMaker solution and most importantly understand the value of consistency in your FileMaker applications.

You may also wish to read FileMaker's Development Conventions for more information and other methodologies.

Enjoy!