FileMaker naming conventions

In a recent discussion at the FileMaker Community a question was asked about why a FileMaker developer would choose NOT to use SQL-friendly field names. It’s an important question that I believe many FileMaker developers often answer incorrectly. Here’s a bit about how my view of naming conventions has changed over time. For reference, a SQL-friendly field name in FileMaker would be a name that:

• starts with a letter
• contains only letters, numbers, and underscore characters
• is not a reserved word (an evolving list of over 200 words including DATE, FIRST, FROM, VALUE, ZONE, etc.)

Developers also often adopt naming conventions that use PascalCase, camelCase, or a variety of prefixes and suffixes to indicate properties of the field or alter the sort order of fields. I was once in the camp that thought it was a best practice to always use these kinds of naming conventions to optimize developer productivity. I come from a computer science background with experience in dozens of different languages, each with its own arcane naming rules. Some of those languages were created when every byte was precious…many computers had just a few kilobytes of memory, data transfer rates were measured in bits per second, and programs and data were stored on punched cards or magnetic tape. I started using some amalgamation of the various rules I knew when I began using FileMaker in 1986. Over the years, my naming conventions evolved modestly as the FileMaker platform changed and I was exposed to other developers’ code. When I joined Skeleton Key about eight years ago I was challenged with a different philosophy: optimize for the end-user’s experience by using natural names for anything that might be exposed to users. In FileMaker, this includes things like table occurrences, fields, and layouts. This approach allows the developer to empower the user by exposing more of FileMaker’s native interface. While I had historically hidden the Status Toolbar and most menu commands, it suddenly made sense to encourage users to use table view, the layout menu, the import/export dialogs, sort dialogs, and saved finds. Field labels matched the actual field names and we no longer needed to hide a confusing and “unnatural” schema from users. We no longer needed to script every sort and export because the dialogs could now make sense to users. Honestly, I didn’t take to the idea immediately. It was an uncomfortable change and I was pretty sure I would eventually hit a productivity wall. But as time passed and my thinking shifted, it was a truly liberating change. From a developer perspective, being able to drag all of a table’s fields from the field picker without having to edit the field labels is a huge time saver. Users have a better experience overall and they often get the benefit of new features that are added to the FileMaker platform without having to make any development changes. There are some downsides to using natural names. However, every single one of them are minor inconveniences that only impact the developer. The FileMaker experience is greatly enhanced when we let FileMaker be FileMaker. When we bring baggage from past experience and ancient languages into FileMaker, we quickly paint ourselves into corners and our users’ experiences are diminished. New developers at Skeleton Key sometimes ask, when should I NOT use natural names? My most frequent answer is that we often work on FileMaker solutions created by other developers (or our past selves) and that if the solution has a consistently-applied naming convention, we should stick to it. We value consistency within a solution more than our own standards. There are also other special situations for vertical solutions, enterprise systems, or integration requirements that sometimes require us to de-prioritize the user experience and adopt a different naming convention for specific systems. Are your FileMaker development standards and naming conventions focused on your experience as a developer or do they truly enhance the end-user experience? Greg Lane is VP of Application Development at Skeleton Key and a FileMaker Certified Developer. About Skeleton Key Skeleton Key helps turn complex, complicated, and outdated systems into true information platforms. Our team of consultants and developers do this by developing custom-fit software tools and reporting dashboards that help businesses find, use, and understand their data, freeing them to focus on and grow their core business. In addition to custom databases and applications, we also provide training and coaching for getting the most out of your existing systems and understanding your unruly data. Skeleton Key is an open-book management company and active player of the Great Game of Business.