This page is part of the internal FileMaker Pro programming standards of Lutz Pietschker. No claims of any sort can be derived from the description of these standards. In particular, no claim can be made that these standards are complete and without errors, and that any of my software projects follow to these standards in part or completely.
The page content was last revised on (ca. 2008)
Go to start page
This document describes the naming conventions for files, tables, table occurrences, layouts, fields, value lists, scripts and custom functions.
All file names shall be all lowercase. Only ASCII characters a-z, 0-9 and the underline character ("_") shall be used. File names shall not exceed 31 characters (excluding the file type extension) and shall be in singular (if not altogether abbreviated).
See database structure regulations.
Table names shall be nouns in singular form, written in UPPERCASE. n:m-link table names shall be formed by "X_", followed by the name of the first table, followed by "_" and the name of the second table.
Example: PERSON; IDEA; X_PERSON_IDEA
Table ocurrence names shall be composed of nouns in UPPER and
,with the first noun (in UPPERCASE) indicating the table of which this TO is an ocurrence. The last noun(s) shall indicate in which context (point of view) the table ocurrence is used. The first ocurrence of a table may be named identical to the table itself.
If necessary (e.g. in case of many data files), the name may be prefixed with the lowercase file reference.
If the table is in a different file than the TO graph, the TO name shall be prefixed with a "$".
The following conventions apply to the "point of view" portion of the name:
Example: PERSON; ADDRESS_Persons; ADDRESS_ThePerson; $SYSGLOBAL
Table occurrences in the TO Graph can be coloured. The colouring rules are:
Layouts that will be visible to the user, but not in the layout drop-down list, take their names from the TO they display, if necessary (e.g. more than one layout per TO) distinguished by additions that describe their purpose; layout names may be in UPPERCASE or
Layout names that are shown in the Layouts drop-down list get names that suit their purpose, these names may also include blanks. However, this should be the exception, since naviagting through layout is usually done by dedicated buttons and corresponding scripts.
Layouts that will not be available from the layout drop-down list may get a suffix:
PERSON; PERSON_raw; Ideas; X_Persons_Ideas; Find Person; Person_find
(of the two last examples, the first is a user dialog, the latter a scripted find mask invisible to the user)
Note: This convention is not valid for field names in language recource files. See the localisation chapter for details about language resource fields.
Field names shall be formed by the field descriptive name in TitleCase, followed by an underline character ("_"), followed by the field type designation suffix (see table below). In some cases the name shall get a prefix (see below).
The field type designation suffixes are:
Examples: IdxIdea_t; IdeaText_t; AmountPaid_n; TotalExpenses_an; CurrentRecord_gt; CurrentLayout_gn; CueIdeaStatus_fnc; FullName_fst; ItemPrice_ln
Fields that serve special purposes get a prefix to indicate their special function:
Value list names shall indicate the content of the list. If the value list is derived from data table field values, the value list name shall begin with the name of the table in UPPERCASE, followed by the field name in plural form.
One value list that is pre-defined is NilOne; it only holds one value, "1".
See the value list chapter for other conventions and information about value lists.
Script (except some special, pre-defined scripts, see below) names are formed by a lowercase prefix indicating the function of the script, followed by an underline ("_"), followed by a descriptive name in
TitleCase. If the script takes a script parameter, the name shall be followed by "
indicates the data that is expected by the script. See also "Scripting Conventions".
Script names may contain blanks. The prefix may be omitted for scripts that are included in the scripts menu of the application.
The possible prefixes are:
Example: btn_DeleteRecord, fct_CreateNewPerson
These special scripts exist in every database file; because of their special function they do not follow the naming convention given above.
Custom function shall be preceded by "lp", followed by the function descriptive name in
TitleCase, and followed by an "_" and the function result type. The result type notation follows the same convention as in the field name (see above).
Custom functions representing static data (constants) follow the same conventions but use UPPERCASE descriptive names.
Example: lpKeyValue_t, lpSUCCESS_n
For more information about custom functions and for a list of standard custom functions see the Custom Functions chapter.
Field definitions, scripts, value lists etc. may be grouped by inserting dummy objects as separators. In case of fields this should be global number fields, otherwise empty objects are used. Separators do not follow the usual naming conventions of the object type, instead, they are named in upper case, preceded and closed by "---" in case of fields and scripts, by "//" in case of layouts:
Example: --- BUTTON SCRIPTS ---, // Web Layouts //
This page is copyrighted by the author according to the
All rights reserved. Lutz Pietschker, Berlin/Germany, 2011 ff.
, last change 2011-03-12