myIdea Logo

My Filemaker Pro Programming Standards: Naming Conventions

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

Document Content

This document describes the naming conventions for files, tables, table occurrences, layouts, fields, value lists, scripts and custom functions.

Naming Conventions


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).

File References

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.


Table Ocurrences (TO)

Table ocurrence names shall be composed of nouns in UPPER and title case ,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:


Table Occurrence (TO) Colouring

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 TitleCase.
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:

Example: 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:

Content Regular Lookup Global Stored
Numeric _n _ln _gn _fsn _fnn _fgn _an
Text _t _lt _gt _fst _fnt _fgt (n/a)
Date _d _ld _gd _fsd _fnd _fgd _ad
Time (Zeit) _z _lz _gz _fsz _fnz _fgz _az
Timestamp _s _ls _gs _fss _fns _fgs _as
Container _c _lc _gc _fsc _fnc _fgc (n/a)

Examples: IdxIdea_t; IdeaText_t; AmountPaid_n; TotalExpenses_an; CurrentRecord_gt; CurrentLayout_gn; CueIdeaStatus_fnc; FullName_fst; ItemPrice_ln

Field Name Prefixes

Fields that serve special purposes get a prefix to indicate their special function:

Value Lists

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 Names

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 " {<param>}", where <param> 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

Special Scripts

These special scripts exist in every database file; because of their special function they do not follow the naming convention given above.

Custom Functions

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.

List Separators

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 copyright note.
All rights reserved. Lutz Pietschker, Berlin/Germany, 2011 ff.

, last change 2011-03-12