FileMaker Tips #3 — Naming Conventions

Naming conventions, or a set of rules for character sequences used for identifiers in a programming language, are a useful practice in any programming language to give developers a clear design of the code.

There are a number of reasons to practice a proper naming convention including:

  • Reducing the effort needed to comprehend source code.
  • Formalizes and promotes consistency within a team.
  • Avoids naming conflicts.
  • Improves clarity in case of ambiguity.

Every language has years of architecting, redefining, and testing naming conventions to obtain all the above benefits when developing shared source code. The same goes for FileMaker! There’s no definitive BEST naming convention, but some great examples have been provided by the veterans of the Claris Community. You can see some of their published designs in the resources at the bottom of the article.

Here, I will be sharing some of the naming conventions I used daily in my FileMaker Development and explain some reasons as to why I’ve chosen these rules over the years.

Schema Definitions

Let’s start with schema definitions ( tables, fields, table occurrences, functions, variables )

Table Names

Tables names I generally like to put in full UPPERCASE. This helps them stand out to me when working within relationships, scripting, and the various interfaces of the FileMaker Pro program.



Field Names

Field names I like to put in TitleCase, where the first letter of each word is capitalized. An alternative to this is to also put underscores ‘_’ between each word. I avoid using underscores as it adds to the length of the field name and I find that I can read TitleCase easily.


  • NameLast
  • PhoneNumber
  • SubmissionDate

Pro-Tip: Make your field names clear about what data they will be storing. Don’t use names like “Field2” or “String”.

Special Case: Globally Stored Fields. When I have a field with global storage turned on, I will prefix it with a lowercase g. This groups all the global fields together and gives me a quick indication that the field is globally stored without my having to go into Manage → Database everytime I need to find my global fields. — An Example: gDateStart, gInvoiceNumber

Primary Keys

Primary and Foreign Keys are also kind of a special case because I like to clearly indicate what the serialized unique keys are in every table since FileMaker is heavily used with relational design. For primary keys, I like to use my own reserved word ID. I will use this field in every table to define the primary key for quick identification.

Foreign Keys

Similarly, I want to be able to identify foreign keys right from the table. This will help me to know what tables have a potential relationship already in place so that I don’t redundantly create fields to build relationships off of. For foreign keys, I will use the ID_ prefix followed by the foreign table name.



Special Case: Multi-keys. If you’re a more advanced FileMaker Developer, you may use multi-keys as a way to create one-to-many relationship for performance or interface designs. When I have a need for a multi-key, i will use the IDS_ prefix. This keeps all the foreign keys together while also indicating this field will most likely contain more than one key within it.


Let’s start with local script variables. These are variables that begin with a single dollar sign symbol $ and are only used within the context of the current running script. For local variables, I will tend to use camelCase formatting. Though we will see the $ prefix at the front, I like to have it differ from a field definition so that it is clearly different.


  • $idCustomer
  • $locationName
  • $endDate

Pro-Tip: Such as with field names, don’t make your variable name ambiguous. They should clearly indicate what the variable is storing.

For Global variables that begin with two dollar signs $$ and are used in a global context for the window, I like to use full CAPITALIZATION for their names with a period ‘.’ to separate distinct words. This helps me quickly identify and group all my global variables in the Data Viewer.



Table Occurrences

In my development, I practice an anchor-buoy design. This could be a whole other lengthy article to define, so if you are not familiar with Anchor-Buoy relational design, please check out this article by Tim Cimbura of LuminFire.

Base Tables ( Anchors )

For each table, I will have a base table that I use as the Anchor table. For these Table Occurrences, I will begin with a four or five-letter abbreviation for the table name, followed by two underscores, and then the full table name, all in UPPERCASE.



The purpose of the four or five-letter abbreviation is to create a quick code word for the relationship graph. Some relationships can span 5 or more buoys from the base table and get lengthy if you use the full table names. Instead, you will use the abbreviated code to identify the connected table.

Related Tables ( Buoys )

For tables that are related to the base or other buoy table occurrences, I will use the following format. A series of prefixed table codes in all lowercase, leading to the current table. I want to be able to quickly see the relationship graph in a text format so I don’t have to jump in and out of Manage →Database while I am writing scripts or modifying layouts.


  • invo_INVL ( starting from the invoice, we are going to the related invoice line items.
  • appt_cust_PHON ( starting from the appointment, we are going to the related customer, and then to the customers phone numbers )

Special Case: Where we may have multiple relationships following the same path or a relationship that is built off of criteria other than a primary-foreign key connection, I will add a suffix to the end of the Table Occurrence name to add clarity to the relationship’s purpose.


- appt_cust_PHON__cells (similar to the above relationship, we have additional relationship criteria to only include phone numbers with a type of “cell”. )

- invo_INVL__billable ( similar to the above relationship, we have an additional relationship criteria to only include line items that are flagged as billable. )

Relationship graphs can be pretty complicated so it's important to have a clear naming convention you can understand from a quick glance or you’ll find yourself creating redundant/duplicate relationships or wasting a lot of time going back to look at old relationships to troubleshoot your code.


Let’s move on from schema and get into our Script Workspace!

Script Names

For script names, I like to group and prefix scripts by features/interfaces before defining their purpose. For example, let’s say I have a series of scripts used for the customer's interfaces. To keep scripts from being ambiguous, i may prefix all the customer-related scripts with “CUST__”. This allows me to visibly find them quickly in the script workspace as well as to quickly search to filter down my script list when I start having 100s of scripts.

Next, I will clearly define a purpose for the script in the name. If the script’s purpose is to send out an email to the customer, I will name it something like “CUST__Send Email”.

How about script parameters? Let’s say we make this Send Email script a bit more modular and allow it to take parameters for including an attachment. For parameters, I will add a list of parameters within the parenthesis to the end of the script name. Similar, to when you pick a function to add to a calculation, it will separate any parameters with a semi-colon. Parameters will be in camelCase format as well.


  • CUST__Send Email ( attachmentPath )
  • CUST__View Invoices For Date Range( startDate ; endDate )

In a future article, I will probably go into more depth about passing and receiving parameters to scripts with JSON functions. So please follow the blog to stay updated!

Custom Functions

Custom Functions are pretty straight-forward and use TitleCase with a “cf_” prefix. The purpose of the prefix is to allow quick type-ahead in calculations to get a list of custom functions and to avoid ambiguity between existing functions or field names.

Similar to script parameters, if the custom function takes any parameters, they will be in camelCase.


  • cf_ConvertDateToSQL ( date )
  • cf_ListKeys ( fieldName )

I hope these naming conventions are useful to your development and please comment if you have any questions or would like to suggest your own naming conventions that you have developed over the years.

Happy coding!




Software Developer and Code Ninja

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Successful Agile Transformations

Coding Stories: Generating Motion

was still not meditating and instead was watching a video on my phone about social media obsession

Product Ops- Powering Product Portfolio excellence

How to Pass Input Files to stdin in VSCode

Why I Decided To Pursue Software Development

Sonic Pi Introduction — Part Two


Man looking at information for CQRS

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jeffrey Henry

Jeffrey Henry

Software Developer and Code Ninja

More from Medium

A Quick Rebuttal to “Stop Using If-Else Statements”

Encourage your team mates to take copy paste code from StackOverFlow(or wherever) ONLY if they…

Vue3: Learning Review

My struggle to recreate a Pokemon ID Tracker.