This is a quick visual overview of the various Claris/FileMaker Pro elements such as tables, fields, layouts, scripts, functions and other objects. Each major element has its own subsection below.
Tablename
dataFieldName
summaryCountField
GLOBALFIELD
CLIPBOARD (a reserved temporary global field)
unstored_Calculation
id (is the primary key in ALL tables)
id_Tablename (is a foreign key)
idList_Tablename (is a pseudo-schema field for multi-key values related to solution schema)*
keys_Tablename (is a utility field for multi-key values used for UI specific functionality)
$variableName
$$GLOBAL.VARIABLE
FunctionalArea » Tablename or FunctionalArea__Tablename
@Tablename (is a name for developer table occurrences)
Tablename: Layout Name (form|list)
portal.layout.objectName
Script Name
Script Name ( with ; parameters )
CustomFunction
~PrivateCustomFunctionVariable
~localVariable
$~privateVariableName
$$~PRIVATE.GLOBAL.VARIABLE
Claris/FileMaker Pro provides a unique feature called a multi-key; not to be confused with a compound, or more commonly, a concatenated key. Typically, a normalized data structure will use a singular key value for each and every record, FileMaker provides the ability to store multiple keys, hence a multi-key, (carriage return delimited) list of values within a text field. Because of this feature, it is possible to create what filemakerstandards.org calls pseudo-schema.
In the rest of the database world, this approach may not be considered valid, where isolated within the Claris/FileMaker world results in a feature which is heavily used by developers. While not suggested for normal use as part of your schema definition within a solution, multi-key values, for the purpose of maintaining relational structure amongst data would use the prefix of idList_ as opposed to the more utilitarian, or more specifically for the UI, keys_ prefix. More details are provided within the section about field naming.
The primary goal of these naming conventions is to create highly readable code. Concerns related to brevity are superseded by clarity and maintainability. These naming standards are also specific to Claris/FileMaker Pro Client development.
Repeat this to yourself!
"Highly readable code". You will love yourself years down the road when you revisit that monster database system and have to relearn what you coded earlier.
Deviations may be required
These conventions do not address Web, Mobile, SQL or external technology based integrations/limitations. Where spaces and or special characters such as the double chevron "»" cannot be used. Deviations are expected to happen.
Tables: are named using a single word in Title case and should not be represented by the attributes of the data it contains. (e.g. "Employee" is an attribute of "People" and "Schedule" is a group of "Events").
| Table name | Result |
|---|---|
| People | good |
| Students | bad |
Plurals: can be used, but should be consistent. If you name your tables in the singular, such as Person, then don't name your events table in the plural. It would be singular as Event. Choosing plural over singular is a matter of preference and depends on how you like to read code. Which reads better?
Event::date
is a singular date value coming from the Event table.
or
Events::date
is a singular date value coming from the table storing all the events.
General vs. Specificity
For clarification, the indication of Students above, as being 'bad' should not be misinterpreted as a bad choice for an actual table name - if a table named Students fits the requirements of your solution. The indication is there because the storage of an actual person who happens to be a Student at the time, should be within a general People table and identified via the data itself (e.g. using either another field as a tag or a join table structure to associate that person as being such a student). A student today is not always a student tomorrow, but they're always a person.
Notice how
Schedule » People::id
will be much easier to read within calculation code as opposed to
People__Class Students::tk_student_id
Wondering about the double chevron character "»" used above? Details in the next section.
Table occurrences: are always suffixed (not prefixed) with their "base table" name and separated using the » character ( Right-pointing Double Angle Quotation Mark – \x00BB ) using a space on either side of the ». The prefix is TitleCamelCase and indicates the functional area or use within the solution. Try not to use spaces within the name of the FunctionalArea of the occurrence name.
Access the double chevron using Option-Shift-Pipe (Mac) or Alt+0187 (Win). You can also simply select the character here on this page and copy/paste it. Once you've done that, just duplicate table occurrences and reassign/rename as needed.
| Occurrence name | Result |
|---|---|
| A Persons Schedule | bad |
| Schedule » People | good |
| Schedule Itinerary » People | bad |
| ScheduleItinerary » People | good |
| Schedule_Itinerary » People | good |
A better way?
This method of table occurrence naming is the inverse of the more popular method of using the "base table" name first. This requires a very strong focus to pre-define functional areas in your solution before hand! Sorting of table occurrence names is based on functional domain instead of base table name. Note, however, it's very easy to rename table occurrences if the functional realm changes for a particular group of table occurrences.
Note: The goal of using FunctionalArea » Tablename is to force a degree of self documentation for the distinct areas of your solution. The FunctionalArea itself can be extended as long as it stays TitleCamelCase. For example:
NavigationAll » Menuitems
NavigationByAccess » Menuitems
NavigationPortal » Menuitems
Where Menuitems is a self explanatory table name and the keyword All may indicate a Cartesian product relationship, the keyword ByAccess indicates the involvement of a possible User table and the keyword Portal clearly indicates its use as a portal table occurrence.
The use of the Right-pointing Double Angle Quotation Mark is simply for readability within the realm of a Claris/FileMaker solution intended for use within the client/server setup. When implementing a web publishing strategy within your solution it is suggested you use the best practice of the various Solution development models. If this is either not possible or preferred, the variation of table occurrence naming would simply replace » with a double underscore __ and remove spaces. Therefore the resulting examples above would look like so:
NavigationAll__Menuitems
NavigationByAccess__Menuitems
NavigationPortal__Menuitems
Using a double underscore differentiates a TableOccurrence__Basetable from id_ForeignKey or key_CONSTANT when scanning through code.
Table occurrences: which are dedicated for internal development and have no relationships are prefixed with the @ symbol and use the same name as the base table.
| Table name | Result |
|---|---|
| @People | good |
| Dev People Table | bad |
Duplicating table occurrences
You don't have to remember the keys for the « and » characters on Windows using Alt key combinations. Keep in mind that simply holding down the Option key (Mac) or Control key (Win) allows you to drag-duplicate a table occurrence. You can also use the duplicate button with the double plus signs. This is an easy way to not have to "remember" what the key combination is for the » character.
The proper naming of fields can have a big impact on the future maintainability and the organization of the Relationship Graph. Follow the guidelines here for a solution which should be easier to maintain.
Note: The standards documented here do not use any special type of field prefixing or cryptic shorthand characters. You won't find a prefix such as gkt_SomeField, where gkt may stand for Global Key Text field. Instead, these standards focus on descriptive field naming with implied use or type.
Don't use shorthand prefixes
For example, customerPicture or productImage clearly indicates the field type of container because both the words "Picture" and "Image" imply what is stored.
These standards do not enforce (but may suggest) the use of certain keywords, such as Picture vs. Image for field names. For field types, such as key fields vs. globals, you will find strict guidelines.
When possible, always attempt to use logical prefix grouping when naming fields. Alphanumerical grouping of similarly related fields makes a solution easier to understand. For example, when the View by: option is set to "field name". The following will be beneficial.
nameFirst
nameLast
nameMiddle
which will group them together and reduce the amount of visual jump and deciphering when scanning structure. As opposed to...
firstName
middleName
lastName
wherein newly added fields, will simply separate the later list as they are added.
Claris/FileMaker uses its Relationship Graph and developer controlled Table Occurrence names to create what is known as "context". This means it's all to possible to overname (yes, we made that word up) fields. Here's an example. Given we have two tables named Events and Products.
It's not necessary to name a field eventName or productName as these will be quite redundant within code. Using the simple name of "name" will often suffice.
Products::name
is more clear versus the more redundant...
Products::productName
and likewise,
Tournaments » Events::name
is better than
Event Tournament::eventName
Remember context!
Context, the table occurrence name, comes with your field name automatically in most cases. Use it to your advantage!
Please note that the standards covered within this section assume you will be organizing and arranging your Relationship graph based on a consistent and controlled field order. This is accomplished using the View by: field name setting within the Fields tab of Manage Database. This should be set before the file is hosted. See the pre-hosting checklist for more information.
View by: "field name" vs. "field type" vs. "custom order"
Using the custom order setting, should you choose to do so, comes with the condition that you ONLY drag your fields into the explicit desired order when the View by: setting is set at custom order. If you temporarily switch to field name order and then drag one single field, you will replace your previous custom order sorting. Hence, these standards do not suggest using custom order, but the more reliable alpha order of by field name.
There are multiple types of key fields within Claris/FileMaker Pro development. Follow these guidelines.
Primary keys in each table are simply, AND ALWAYS, named "id" – Fields are identified by Claris/FileMaker Pro inherently by the Table » Occurrence::id nomenclature. (e.g. Schedule » People::id) where Schedule » People::primaryKey is superfluous.
| Field name | Result |
|---|---|
| id | good |
| Primary Key | bad |
| pk_People | bad |
Foreign keys within any table are named using the "id" keyword and an underscore followed by the exact same TitleCase version of their table name. (e.g id_Tablename). The underscore within the field name distinguishes a foreign key from other camelCase field names and the primary key of "id".
| Field name | Result |
|---|---|
| id_People | good |
| f_personID | bad |
| id_Events | good |
| kfEvents | bad |
Serial Numbers vs. UUIDs
While not a required standard, the majority of contributors to these standards suggest using universally unique identifiers (UUIDs) for primary key values. This avoids some common issues with FileMaker's default serial value options. See the best practices for key values section for information about using UUIDs.
Constant keys, or better known as global keys, should be prefixed with the keword "key_" or "keys_" and follow the format used by GLOBAL fields when set as global. Because these types of fields are not primary keys, yet they are used for utility relationships, they can be interpreted as foreign keys of a special type.
| Field name | Result |
|---|---|
| key_PEOPLE | good |
| zkf_ConstantOne | bad |
| keys_ALLCUSTOMERS | good |
Special Note: try to name the key functionally relevant and easily identifiable, for example keys_ALLCUSTOMERS may indicate an unstored constant calculation derived from another relationship using a List() function for the purpose of a cartesian relationship. Also note the plurality of the prefix. Use plurality to indicate a singular key vs. multiple.
Multi-key fields are a feature unique to Claris/FileMaker Pro. They provide a feature which allows for the implementation of pseudo-schema (described later) or for a purely utilitarian feature of being able to drive data display within Layouts - known as the UI of a solution. Because these multi-key values, which are simply what Claris/FileMaker calls a List (see the List() function) can be anything from a list of serial number values to UUID values to a list of concatenated keys, it becomes useful to easily identify such use of these fields. The two prefixes used to identify these fields are idList_ and keys_. Choosing one over the other can be subjective, but follows these guidelines. If the field storing multi-key values relates to the structure, commonly known as the schema for a solution, and uses id values, then idList_ is preferred. The keyword "List", within idList_ implies the field stores multiple values. When the field is used for the purpose of utility, then the prefix keys_ is preferred. The keys_ prefix implies multiple values due to it being plural as opposed to the Constant key_ prefix above. When used in the context of a relationship, the trailing portion of the field name is typically the Tablename to which the foreign keys are being related to.
| Field name | Result |
|---|---|
| idList_People | good |
| keys_Participants | good |
| keys_INVOICES | good |
In the above examples, idList_People might be used to maintain a pseudo-schema relationship between a people (customers) table and an invoices table. This type of use would be in place of a normal Join table and is a subjective decision based on the criteria and needs of the solution. keys_Participants may represent a record local list of id values creating a many-to-many relationship from one record to many records within a Participants table. The keys_INVOICES field is clearly a global field used for the purpose of holding any number of multi-key values which may be id values, serial values or concatenated keys for the purpose of data display of invoices within a portal.
Pseudo-schema
When considering the principles behind database normalization, a typical approach to structuring data is to use a join table. However, in the world of Claris/FileMaker development, a relationship between two tables can take advantage of a feature known as a multi-key field. This single field (whether local or global) can store more than one single key value as a return delimted list. As stated on this web site, this feature is somewhat unique to FileMaker and does not follow the principles of data normalization. Strictly within the context of FileMaker however, using this method of relating data is perfectly viable and is being called pseudo-schema here because of its uniqueness. The most common use of multi-key fields is for the purpose of driving data display within the user interface and not for data structuring. It is possible, however, to maintain, as part of the solution schema, multi-key values within fields for the purpose of data structure. Use the above guidelines to direct your use of these prefixes.
Shared keys, which are fields that are foreign in nature, yet do not correlate to any one specific table, should use a fixed name within all tables throughout the solution. These standards suggest the use of the name id_Any where Any can be the primary key from any given table. One example of a shared key would be a foreign key within a shared Notes table. Where the id_Any field could potentially hold the primary key value for tables named People, Events, Invoices, Estimates, etc. In this scenario, the Notes table is used to store notes for multiple other tables.
Developer note: the use of Shared keys is typically a practice which utilizes additional predicates within relationships, such as a specialized field used to qualify which table a specific note belongs to.
Data fields, those used for solution data, use lowerCamelCase starting with a lowercase letter. Starting with lower case differentiates the string from function calls which are Title Case. No spaces or underscores should be used.
| Field name | Result |
|---|---|
| customerFirstName | good |
| Customer First Name | bad |
| CustomerFirstName | bad |
Summary fields are prefixed by the word "summary" and their return type before their identity. This facilitates quick and easy recognition.
| Field name | Result |
|---|---|
| summaryCountMembers | good |
| summaryMemberCount | bad |
| memberCount | bad |
| summaryMaxId_Event | good |
| summaryMinAmountSpent | good |
| summaryAvgPaid | good |
| summaryTotalUsers | good |
| summaryStdDevWhatever | good |
| summaryFracTotalMetrics | good |
Note the use of the underscore above, it indicates a summary of a foreign key (covered below)
All GLOBAL fields are UPPERCASE and one single word. This easily differentiates global data from all other types.
| Field name | Result |
|---|---|
| CREATE | good |
| globalCreate | bad |
| global_Create | bad |
| EVENTFILTER | good |
| CUSTOMERSEARCH | good |
| CLIPBOARD | good |
| g_GlobalFieldName | bad |
Underscore allowance
Based on certain situations, when global fields do not read well as a single word, you can optionally using the underscore as part of these standards. So GLOBALLANGUAGE would become GLOBAL_LANGUAGE. However, it's suggested you attempt to alter your word choices to attempt to use the single string approach.
Unstored calculated fields are prefixed with the word "unstored_", and that prefix is separated from the rest of the field name with an underscore. Always try to use descriptive adjectives or actual nouns to help identify the field type (e.g. Count in unstored_userEventCount indicates a numerical data type). Because unstored calculated fields are somewhat similar to GLOBAL fields you can optionally capitalize the words after the underscore.
| Field name | Result |
|---|---|
| unstored_userEventCount | good |
| uc_EventCount | bad |
| %invoiceStatus | bad |
| unstored_USEREVENTCOUNT | ok |
| unstored_invoiceStatusImage | good |
The reason we don't suggest UNSTORED_INVOICESTATUSIMAGE is because the "unstored_" prefix provides grouping where a collection of UPPERCASE grouped values dilutes the use of uppercase for GLOBAL fields. But, in most cases, an unstored calculated field acts just like a global field.
Default auto-enter options provided by Claris/FileMaker are grouped by a designated prefix and identified by their respective name. These include the following defaults or variations thereof.
creationAccount
creationTimestamp
creationHostTimestamp
creationUser
modificationAccount
modificationTimestamp
modificationHostTimestamp
modificationUser
Note that not all fields are required. These are just some suggested names.
| Variable name | Result |
|---|---|
| $variableName | good |
| $variablename | bad |
| $variable_name | bad |
| Variable name | Result |
|---|---|
| $$APP.SETTINGS.ACCESSLEVEL | good |
| $$APP.SETTINGS.LANGUAGE | good |
| $$USER.PREFERENCES.DISPLAY | good |
| $$user_settings | bad |
Layouts can be well grouped using the folders provided within the Manage Layouts dialog. Depending on the size of the solution, it may be desirable to have context clarified within the name of the layout. The following are suggested standards and not followed strictly.
| Layout name | Result |
|---|---|
| People: Customer List | good |
| People: Customer Search | good |
| People: Customer Detail | good |
| Events: Utility: Copy All Records | good |
Layout objects: are prefixed by their corresponding reserved name and use a dot separator. The dot identifies them as layout objects within calculation code. The number of levels used is currently arbitrary based on the solution. Reserved object prefixes are the following
| Object name | Result |
|---|---|
| field.customerName | good |
| portal.sideBar | good |
| webview.help | good |
| customer field | bad |
| invoices_portal | bad |
| Script name | Result |
|---|---|
| Sidebar SelectRow Customer List | good |
| Select Customer in Portal | bad |
The later example is too generic and the goal is to easily identify the area of use for the script within the solution.
| Script name | Result |
|---|---|
| Script Name ( with ; parameters ) | good |
| Script Name ( with , parameter ) | bad |
Not for url use
Note that the use of spaces and parentheses within Script names is not advised for scripts used within any type of web deployment of a solution where the script is referenced within a url.
fmp://192.168.10.0/FileMakerFile.fmp12?script=ScriptName¶m=SomeValue&$variableName=10
Notice the simple name of ScriptName where Script Name ( with ; parameters ) would have to become the following when used within a url.
Script%20Name%20(%20with%20%3B%20parameters%20)
Easier script filtering
As a solution grows in scope and complexity, it's advantageous to be able to use FileMaker's script filtering within the list of scripts. See the best practices for Suggested script naming prefixes
| Custom function name | Result |
|---|---|
| ObjectID | good |
| IsLocalFile | good |
| ValueToggle | good |
| object.id | bad |
| Custom function name | Result |
|---|---|
| ~PrivateCustomFunction | good |
| _Private_Custom_Function | bad |
Grouped Custom Functions (using the prefixes of Object, Script, SQL & Triggers)
ObjectFieldID
ObjectFieldName
ObjectLayoutID
ObjectLayoutName
ObjectLayoutNumber
ObjectScriptID
ObjectScriptName
ObjectTablelD
ObjectTableName
ObjectValueListID
ObjectValueListName
ScriptOptionalParameterList
ScriptRequiredParamterList
SQLDebugResult
SQLFieldName
SQLTableName
TriggersAreActive
TriggersDisable
TriggersEnable
TriggersReset
Internal Functions (using the keyword "Values")
LeftValues
LocationValues
MiddleValues
RightValues
SortValues
UniqueValues
If your function returns a return delimted list of values or uses them as input, then consider using the keyword "Value", which Claris/FileMaker already does, within your custom function name. (e.g. ScrambleValues, ValuePosition, ValueToggle)