Updated Naming Conventions

When you work within a development environment long enough, you end up realizing where some of the pain points are for certain types of situations. For FileMaker Pro development, and many other systems, one of the biggest pain points is maintenance of a growing system. Where older code may be replaced instead of refactored.

What ends up happening is the older, unused code just sits there and only contributes to the growing mess which is what I call the "Giant Ball of Spaghetti Mess" that is a FileMaker solution gone awry.

So, what is one of the best solutions for keeping a system easy-to-maintain while also being able to understand what you're doing while developing? Naming standards or conventions of course. In this video, I discuss some updates to my own personal conventions which will lend themselves to helping to make a FileMaker solution much more streamlined.

If you consider your own FileMaker solution a special kind of mess, then give this video a peek for information about why naming certain things in certain ways can give you a helping hand for keeping your FileMaker solution easier to maintain and update.

Comments

Hello, Matt:

I've been a "disciple" of yours and the filemakerstandards.org for many years. Having developed many systems in an enterprise WAN environment for many thousands of users and other developers, I've honed a system of naming conventions for fields based on the filemakerstandards.org naming conventions. In general, my systems use a prefix for the data domain, such as "data_", "Info_", util_", etc.

I still organize by "custom", since I use 'separators" based on a GLOBALS table, but for the most part, these prefixes and their following prefixes help us to discern not only if this is a field of data, supplementary info, or used in a utility fashion — they tell us if this is an unstored calc ("c_"), scripted calc ("sc_"), auto-enter calc ("aec_"), or summary field ("s_ListIDs").

Following those, we know the data type, by using "num_", "boo_", "ts_", "text_", "date_", "time_", etc. So…for instance, we have a data field holding a street address…It would be named "data_txt_AddressStreet". If it were a field used to supplement info for the data, it may be named as "info_txt_AddressStreet", or ""util_c_txt_AddressStreet" if it were used in a "utility" fashion as an unstored calc of a text string result.

The unstored count of found records (which is a standard field in all of my tables) would be rendered as "util_c_num_FoundCount" (we have evolved this from "c_Found_Count" to "util_c_FoundCount" to "util_c_num_FoundCount" today). The list of ID's would be "s_ListIDs". This method not only sorts well by name, but provides valuable insight into the type of field (data, info, util), it's data type (text, number, date, timestamp, unstored or auto-enter calc, etc.), and it's name.

Before you dismiss this, I will say I have 3 decades of experience and found filemakerstandards.org the first real logical starting point upon which I've based these diversions. I respect your work (as a lifelong subscriber!), and welcome a private screen share to debate the topic.

Posted by: mr_scott
Tue, 10/01/2019 - 5:46am

Hey Scott,

We're not actually in disagreement. Each system will dictate variations based on who is working on the database. Your systems are using clarifications to the extent which they are not overly cryptic based on single character abbreviations - at least most of them.

You said, "my systems use a prefix for the data domain, such as "data_", "Info_", util_", etc."

This is exactly something I would do in a system as large as what you work on - knowing what you work on. The only difference, for me, might be using the full word. So s_ListIDs becomes summaryListIDs for me.

Regarding the "custom" sorting option I'm now relying on the alpha order for simplicity, hence the full word prefix for things like GLOBAL and UNSTORED. Using the word "Global" implies the field can be edited, where "Unstored" is known to be non-modifiable.

Regarding your use of "data_txt_AddressStreet", the field itself and it's name are now not group-able according to implied use - such as addressStreet, addressCity, addressState, and so on. But this only impacts you if you're sorting by name. Since you're sorting by custom, then you can arrange fields as desired. When using the sort-by-name option, all fields prefixed with "data_txt" would be grouped together - which would hinder the system for grouped "like kinds of fields" when sorting by name.

In our newer world of how FileMaker presents the data type iconically, I'm not as worried about including the type into the field name. Plus, I can always sort all fields by type if I need to see that grouping. I will always try to include the data result as part of the name if possible - such as summaryTestScoresAverage. Where both summary field and the average can clearly be parsed.

Given that you started developing your system using the "custom" sort option, and likely before FileMaker's use of icons for field types, I would see no point in changing your own standards. I'm just providing updated insight into the direction I'm heading. Where your field of "util_c_num_FoundCount" tells you it's purpose is utility and it's a calcuated (stored or unstored?) number result, my use of UNSTORED_FOUNDCOUNT tells me the same, it's unstored and it's a number since I used the word COUNT.

Of course this whole discussion is also predicated on the premise that we're not confusing users of the system by allowing them to see the exposed field names through Sort dialog boxes or other places where users can choose fields. Now, if FileMaker would just implement field alias names we'd have a pretty close to perfect system.

Thanks for the feedback and input!

-- Matt Petrowsky - ISO FileMaker Magazine Editor

Posted by: Editor
Tue, 10/01/2019 - 2:38pm

We've created internal "standards" documentation for naming conventions, white space, commenting, and other best practices. That includes prefixing summary fields with "s_", unstored calcs with "c_", calculated values set through scripting "sc_", and auto-enter calcs with "aec_". Fields designated for "phase-out" have their own prefix as well, so we can ID for "cruft" removal at a later date.

Additionally, we name all GLOBAL fields in uppercase, per FM standards.org.

As far as sorting by field name, our system works well, as it groups the fields by domain — for the most part. For instance, "data_txt_AddressStreet", "data_txt_AddressCity", "data_txt_AddressState", and "data_txt_AddressZip".

Even though FM now provides icons for field types, it doesn't tell us if a calculated field is to produce a text, number, or other result, but our naming conventions do provide that insight.

Thanks for your response.

Posted by: mr_scott
Thu, 10/03/2019 - 3:23pm

I like to use "_" as a prefix for global fields (i.e., _name). This groups them and places them together at the top of the field list when sorted by name. Whenever I see that prefix, I know the field is a global, so I don't need to add anything else to identify them.

Posted by: jonro
Tue, 10/01/2019 - 10:25pm

your quote on the right of what you pasted (or typed) is being used as part of the url --- remove that and you are fine

Posted by: ntowler
Thu, 11/28/2019 - 9:25am

Hi Matt,

Did you happen to ever release your custom app for storing code, I could really do with something like this.

Ciaran Harand

Posted by: charland999
Mon, 01/09/2023 - 6:18pm

Hi Matt,

Did you happen to ever release your custom app for storing code, I could really do with something like this.

Ciaran Harand

Posted by: charland999
Mon, 01/09/2023 - 6:18pm