FileMaker Naming Convention

Naming convention is the exceptional requirement which is crucial in any custom app development. The following rules are guidelines for our development on daily basis. We use it through all our solutions. This article will let any FileMaker developer to better understand the code we create and extend it.

File naming

1. Should use only the characters.
   • Upper & Lower case aA – zZ
   • Number 0,1,2,3,4,5,6,7,8,9
   • Single and double underscores “_” “__”
2. Could contain spaces.
3. Should NOT start with numbers.
4. Should NOT use file name to indicate versions.
5. Should NOT contain periods other than the single period used for the extension. Should consistently use singular or plural names.
6. Individual words should consistently be separated using one of the following methods.
7. Individual words should consistently be separated using one of the following methods.
   We use Word Separation Methods (File Names):

   UpperCamelCase	MyFileName
   Type_CamelCase	dev_FileName

8. Should contain the .fmp12 (in lower case), regardless of platform.
9. We usually make a single file solutions, unless customer requires multi-file solution specifically.
10. Multi-File Solutions – Are a group of files that comprise all the tables for the entire solution. In any multi-file solution there are primary files and support files. The primary goal of multi- file solution grouping is to easily identify the files that comprise a solution. In many cases, natural names can be used. We consider the same example using the standard aware recommendation. This aids in a few areas. First, it clearly identifies the primary file, secondly, it clearly identifies the support files, and lastly, it indicates the collection of files as a group.
    • Helpdesk_hd.fmp12
    • hd__Tickets.fmp12
    • hd__Reports.fmp12
    • hd__Inventory.fmp12
11. Support File(s) – Each support file should contain a prefix, defined here as the Logical Solution Identifier (LSI). The same LSI should be used for every support file in the solution. The LSI should follow the general conventions and should always be separated from the name with two underscores “__”. The use of two underscores aids in identifying the LSI from the file name, which could use a single underscore as a word separator. The LSI can be any length but should be consistent throughout your solution.
    Syntax (Support Files):
    <<LSI>>[__]myFileName[.fmp12]
    • LSI (Logical Solution Identifier) – required, developer defined Denotes files are logically connected
    • “__” – required
    • Separates LSI from File Name
    • myFileName – Descriptive File Name
    • .fmp12 – required
    • All files should contain the “.” (period) followed by fmp12 extension.
12. Primary File(s) – You may elect to include the LSI in the primary file(s) as a prefix or suffix. In either case the LSI should always be separated from the name with two underscores “__”.
    Syntax (Primary Files):
    myFileName[__]{LSI}[.fmp12]
    {LSI}[__]myFileName[.fmp12]
    • LSI “Prefix” (Logical Solution Identifier) – required, developer defined Denotes files are logically connected
    • “__” – required. Separates LSI from File Name
    • myFileName – Descriptive File Name
    • LSI “Suffix” (Logical Solution Identifier) – required, developer defined Denotes files are logically connected
    • .fmp12– required. All files should contain the “.” (period) followed by fpX extension

Examples:

Primary File: MySolution__xxx.ffmp12
Support File: xxx__MySupportFileA.fmp12
Support File: xxx__MySupportFileB.fmp12

Table naming

Table names are not exposed to any major degree within the development environment. Interacting directly with tables is generally limited to associating a table with a Table Occurrence, found on the Relationship Graph. All data interactions are through the Table Occurrence. It is important to make this distinction. While many of the dialog boxes will use the term ‘Table’ you will actually be utilizing the ‘Table Occurrence’.

1. Should contain only the character
   • Upper & lower case aA-zZ
   • Numbers 0,1,2,3,4,5,6,7,8,9
   • Single and double underscores “_” “__”
2. Should NOT contain spaces
3. Should consistently use singular or plural table names.
4. Individual words should consistently be separated using one of the following methods.
   We use Word Separation Methods (Table Names):

   Single Underscore (Title Case)	My_Table_Name
   Single Underscore (UPPER CASE)	MY_TABLE_NAME

5. Should NOT use any FileMaker Reserved Words
6. Should NOT use any SQL Reserved words.
7. Table Categorization – As mentioned in the problem definition, some developers like to indicate the ‘type’ of table or the function of the table within the table name itself. If your development practice needs to include this we recommend the following syntax.
   Syntax: T{numbering}{Separator}{TableName}
   • T – we always use “T” letter to identify FileMaker tables in the Manage > Database.
   • {numbering} – required; Developer defined contextual numbering.
   • {Separator} – required;
     [_____] A five underscores should be used to indicate the separation and identification of contextually primary Table Name.
     [_01_] A numbered separator with underscores should be used to indicate the contextually associated table for secondary Table name.
   • {TableName} – required; Primary Table should be with CAPITAL letters, although associated table should be in regular letters.

Example:

T01______CONTACTS – Primary table for Contacts
T01_01_Phones – Contextually associated table to Contacts table
T01_02_Emails – Contextually associated table to Contacts table
etc.

Field naming

Table Occurrence naming

1. Should use only the characters
   • Upper & lower case: aA or zZ
   • Numbers: 0,1,2,3,4,5,6,7,8,9
   • Single and double underscores “_” “__”
2. Does NOT contain spaces
3. Does NOT start with a number
4. Does NOT contain periods
5. Individual words should consistently be separated using one of the following methods.
   We use Word Separation Methods (Table Occurrences)

   Single Underscore (lower UPPER CASE)

   MY_table_OCCURRENCE_name

6. Anchor Buoy / Hierarchical Table Occurrence Grouping (HTOG) Method
   1. This method of Relationship Graph design takes a collection of Table Occurrences (TOs) that are connected by relationship lines, and adds structure and rules.
   2. In the September 2005 issue of FileMaker Advisor, Roger Jacques of Soliant Consulting, explores this method in an article entitled “Managing the FileMaker Pro 7 Relationship Graph,” It is impossible to provide the full details of this method in this document. However, I will use his description as the basis for some examples. He provides the following description of the hierarchical/Anchor model.
      • “The hierarchical nature of the Anchor Method is based on a pattern. Every TOG has an anchor TO and that TO is serviced with related data via any number of threads of buoy TOs. This hierarchical model lends itself to the requirement of only one path between any two TOs. After you start a thread, you might add whatever TOs are required to retrieve related data. Here’s a rule I strictly follow: Don’t join two TOGs with a relationship line and FileMaker will not let you make a circular reference.”
      • “The anchor TO is always the farthest to the left and the supporting buoy TOs cascade off to the right. You can add TOs as you need them, providing access to related data for the anchor TO. In practice, threads rarely get longer than four of five levels deep.”
        
      • “Note that both threads use the same tables, but for different purposes. In this example the lower thread is based on the primary and foreign key relationships for the three entities, and lists all roles and actors for the current move. The upper thread lets users select a portal row for the roles then see details for that role and actor in related fields.”
7. Benroy database Data Modeling is created based on Anchor Buoy method. Anchor Buoy (AB) is arguably the most widely adopted FileMaker development convention because it gives an excellent visual pattern and language for tackling this.
8. We have to extend the traditional naming convention due to so huge amount of tables. Here is an example how table occurencies (TO) are named:
9. Syntax: <T>{AnchorNumbering}[_]BuoyNumbering[_]MainAnchorTableName[_]SourceTable[_||_]Key[||]
   • “AnchorNumbering” – Table number (T05) which is the same as it is in Tables number.
     • Table (05) is the Companies table and is named: T05_____COMPANIES, T0500 – If the main table has subtables so it has the number before name and this number is showed as 3rd and 4th digit.
   • “BuoyNumbering” or Subtables – tables related to main table from business logic perspective, i.e. Projects have Job Orders, Estimates and more.
     • _23 – Que number which this TO is related to main Anchor. Que is created based on the tables names que. This number shows only first Buoy.
     • _23a – The letter “a” means that this TO is related to main Anchor through first Buoy and is described as second Buoy.
     • _23a1_ – The digit “1” means that this TO is related to main Anchor through first and second Buoy and is described as third Buoy.
   • “MainAnchorTableName” – The name (_companies_) of the main (Anchor) table.
   • “SourceTable” – The name (_INCOMES_ ) of the Source table for this current TO.
   • “Key”- Main key which is used for this relationship. If there are more than one key so this part could be named as you want to get the most meaning to this TO, i.e. “_||_Unpaid_||”

Examples:
T0500_23a2_companies_INCOMES_||_kp_Income_ID||
T0500_23a3_companies_INCOMES_||_Unpaid_||

Layout naming

Calculation documentation and formatting

Value list naming

Custom Function documentation and formatting

Account naming

Conclusion

If you would like to investigate other naming conventions which has been used in FileMaker developers community, please search the web or use the guide from FileMaker Inc.