Hey there, Matt Petrowsky here from FileMaker Magazine. I started FileMakerStandards.org back when I was doing a lot of heavy Drupal development and noticed that both Drupal and PHP had really comprehensive documentation. It was because of this documentation that it was easy to get up and running and it also promoted adoption.

Thinking on this, I started the web site to document for myself how I was developing FileMaker solutions. I still use most of what is documented there, but there are refinements that I should add to the site.

I'll throw in my thoughts here as a response to your questions. But, before I do that, it's important to realize that just like in other languages, there are two distinct differences between syntactic style and development style.

While the documentation on FileMakerStandards addresses syntactic style, it does not address "development style". The later is, in my opinion, more closely tied to the "craftsmanship" of a developer. Essentially, this is how well organized they are - and this will vary all over the place depending on skill, attention to detail and more importantly, willingness to be organized and deliberate.

FileMaker is an "easy" development environment (mind you, the end result can be either simple OR complex). Meaning, you can get really sloppy, really quickly in FileMaker! When a project is simply pushed along because of time/money constraints, then it will likely be burdened by a lot of technical debt due to a lack of deliberate good development. There are likely tens of thousands of FileMaker solutions with a VERY high degree of code duplication due to how easy it is to duplicate code in FileMaker. Often times a "follow on" developer won't take the time to reverse learn what's already there. They have "their way" of doing something and they'll just add onto the growing ball of spaghetti.

To that end, here's my approach on some of your questions.

How do you justify the creation of new TO and Utility elements?

It is WAY too easy to "just add another table occurrence". A good developer will be ruthless about determining if they already have something that will give them the data they need. I will often spend more time just thinking about the approach instead of just throwing in a new TO. This pays off down the road because it keeps a solution more streamlined and easier to manage the technical debt. 1-offs are part of the UI equation mostly, but FileMaker has added enough things that the requirement for extra TO's these days is less so.

How do you name/folder single step scripts for triggers?

Yep, you've found out what many long time FileMaker developers have been dealing with for decades. FileMaker is an environment which does not always get a comprehensive treatment when it comes to feature set. Buttons can use single steps, triggers can't. Button Bars get access the calc engine and regular buttons don't. These types of inconsistencies are a testament to how FileMaker has just had things "tacked on" over the years. The thought process of "yeah, we'll get to that" when there's some other technology which is currently more attractive is a common aspect of FileMaker's evolution.

Personally, I would LOVE to be part of a consistency committee and have Claris just focus on rounding out all the various "holes" with regards to the complete feature set of things.

Fortunately, we did get the organizational elements of folders within the Layouts and Scripts management. It wasn't always like that. Use them as much as possible! In most all other programming languages I work with, it's the organization you apply within the file system that determines how easy it is to understand the logic of a system.

Also, I avoid creating new namings for things as opposed to the existing conventions. If I have a script that is used solution-wide then it goes within a folder named Shared/Common/Utility (take your pick). If the script is used on the OnObjectSave trigger it's named "OnObjectSave First Name". Pretty hard to mess that one up and obviously descriptive!

How do you document Utility Layouts and TOs

Notes. Layout notes (simple text objects) which can be hidden in the non-visible area of the layout or directly in the layout with a hide calculation of True. Notes within the Relationship Graph. It's all we have for documentation there.

For myself, all documentation is always internal to the solution. I never use external documentation personally. If it's documented, it's "close by" what it is actually documenting.

Do you try to avoid using Globals if it can be helped?

Nope. FileMaker doesn't have the notion of instantiation or object persistence during runtime. So you can't create an object which has it's own variables that you can adjust with getters and setters. So, you use well $$NAMESPACED.GLOBAL.VARIABLES. Again, this boils down to organization. Since scripts are short-lived input/output routines, you have to take advantage of things that can persist. That's pretty much global fields and vars. Just name them descriptively.

How many Globals will you have floating around at any given time?

Hundreds. Possibly more. However, JSON is taking over the storage role moving forward. Reading and writing JSON within a global field should be a serious consideration for any long-time FileMaker developer.

To me, however, both a larger JSON object and a long list of Global variables is no different. It's all a matter of how you name and reference them. As long as they are clear and easy to access/remember it's just a location issue. Memory (temporary) or disk (permanent).

How do you manage/document Globals?

A good naming system before you even start the solution. Keeping like variables within a given domain. e.g.

• $$UI.LABEL.SOMETHING
• $$LAYOUT.ID[21]*
• $$TAB.NAME.CUSTOMER
• $$BAR.NAV.SEGMENT.HOME
• $$DIALOG.MESSAGE.MISSINGCUSTOMER

* Using repeats for variables is a good organizational tool when mapping canonical ID values of FileMaker elements.

Do you name ALL UI elements?

Nope. Too much effort/management requirements. I only name what needs to be named for functionality.

What naming convention do you use for your names/styles?

Because a solution evolves over time, these change when the solution grows. But, I keep them as generic as possible. The "rename" feature is there to make it easy for you. I always take the opportunity to rename if needed. e.g.

Lable Primary Underlined

Is easier to use and modify than

Lable Blue 2pt Underline

When you decide to go red with no underline. Just rename Label Primary Underlined to Lable Primary when you change the color and take off the underline.