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 |
Bad |
addressCity |
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 convention for naming summary fields is a prefix of "summary".
- The example UUID functions in the FileMakerStandards.org GitHub repository all begin with "UUID".
- The convention for privately-scoped entities, including custom functions and Let() variables, is to prefix them with a tilde "~".
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
9 Comments
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
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
Jeremy Bante
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.
Matt Petrowsky
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...
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.
Jeremy Bante
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?
Matt Petrowsky
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.
Jeremy Bante
I like it.
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!
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