Many lists of objects in FileMaker give us the option to view those objects in alphabetical order. In calculation dialogs, the list of available functions is in alphabetical order (even when you choose to group functions by type), for example. Related objects will cluster together in alphabetically sorted lists if they begin with the same characters. By prefixing related objects with the same word(s), developers can suggest that they represent similar information or that they are inter-compatible in some way.

city
fax
firstName
lastName
mobile
postCode
phone
state

Bad

addressCity
addressPostCode
addressState
nameFirst
nameLast
phone
phoneFax
phoneMobile

Good

The general rule of thumb is to name in the direction of general or wider scope to more specific scope. This forces grouping when a list is sorted in alphabetical order.

Group prefix naming is similar in spirit to the "apps" variant of Hungarian notation, but more verbose. Practically always, some objects in databases are more closely related to each other than others. For example, a field for storing a contact's first name has more in common with the field for last name than it has in common with a field for a phone number. For another, a $windowName variable is related to a window, just like a $windowWidth variable; but we'd like to distinguish those from $objectName and $objectWidth variables referring to properties of a different entity. The database doesn't know that, but developers and users need to.

Some conventions and functions on FileMakerStandards.org already follow this idea:

The last example is a "sigil", a single-character type identifier. Sigils can be a more concise notation for entities that get used very frequently, but they can be confusing to developers who are unfamiliar with your conventions. Reserve sigils for naming entities critical to techniques you find yourself using very frequently in many unrelated contexts, techniques you can't live without. It may even be a good idea to avoid using sigil's then. For one example, the name-value script parameter functions all use a hash character "#" prefix. For another, this website suggests using UUIDs for primary keys in every table, but the example functions all still use the "UUID" prefix rather than a special-purpose single character.

Known Prefixes

Custom Functions

  • Device*: for functions dealing with the device and/or platform FileMaker is running in, e.g., DeviceIsServer, DeviceIsMac, DeviceIsPad, etc.
  • Error*: for error handling functions, e.g., ErrorDescription
  • Key*: for detecting and handling keystrokes, e.g., KeyCode, KeyShift, etc.
  • UUID*: for creating and manipulating universally unique identifiers, e.g., UUIDRandom, UUIDGetAsRFC4122
  • Value*: for functions dealing with return-delimited lists, e.g., ValueSort, ValueExists
  • No labels

9 Comments

  1. Anonymous

    Jeremy I agree with this. The only issue it gives is when using MergeVariables on a layout as the extended length of field names then makes it often necessary to use the ugly workaround of making everything after the first '<' 6 point especially when the contained data is much shorter than the field name.

    John Renfrew

    1. Anonymous

      I'm not sure I follow this, John.  I often use merge fields whose names are substantially longer than the contained data.  I make the field left-aligned and allow the text box to run off the layout to the right.  When displayed with data, or printed, the information is in the correct place.  

      Have you found situations in which this doesn't work well and requires shrinking the merge field text to 6pts?  Or have I misunderstood your point?

      -Matthew Miller

    2. John, I agree that the 6-point type trick is a less than ideal workaround; it's even worse with related merge fields. I'm hoping that the next version of FileMaker does something about it; it's certainly been a developer complaint for long enough. In the interim, I sometimes find that a thesaurus comes in handy for finding shorter synonyms for prefixes.

      1. There was a REALLY, and I mean REALLY good April fools post about FileMaker 12. In it, one of the best suggestions I've ever heard about was...

        Each field may have an alias. There are different reasons why and when to use an alias. For example:

        • The alias is used as the field label when the field is added to an layout. Without an alias the original field name is used.
        • In import/export and sort dialogs you may use alias instead of field names. In case you use cryptic field names with pre- suffixes (_uc_TestSample_limit_n) alias are a great help. The common user will see a more readable name like “Sample Qty” and, if exported into Excel, the column will have the same name.

        In privilege sets you can set the option whether field names, aliases, or both are accessible. This will definitely help an inexperienced user to select the right field in the sort dialog.

        With this feature comes a the function GetFieldAlias( field ), returning the alias assigned to the field. There is no function like GetFieldNameByAlias. One reason might be, you can assign the same alias to different fields.

        Jeremy, I totally agree and also need to do this myself. I'm going to move it to the Best Practices and I think we should evolve it by adding some suggested standardized prefixes.

  2. I disagree with the page renaming. The "file naming prefixes" is more concrete, but I intended it to apply to any object we can name: variables, fields, custom functions, etc. Perhaps I can add some more concrete examples to the body of the page?

    1. Take off the specificity? Simply "Naming Prefixes". And take out references to the word "field". The Good/Bad examples are more concrete, but I see your point.

  3. Anonymous

    I like using an underscore in place of a space (Date_Sent) so Find and Replace can be used to make a user layout pretty. This also makes it easy to remove suffixes (_c, _gn, _aec) which I put an nearly all but plain text fields). I would Prefer Filemaker provide a visual hint so the suffixes would not be needed). Merge fields; 6pt? 2pt!

  4. Anonymous

    I generally like an underscore (_) after the prefix for:

    * greater readability

    * to differentiate from other field names that are not grouped with a prefix

    Matt, I would post non-Anonymously except the "Sign Up" link is broken in Safari and Firefox (just send an email)

    Tony White