FileMaker Coding Conventions

By Matt Petrowsky

Almost every, and I mean EVERY, developer has their own take on FileMaker development. I guess it's one of those aspects of FileMaker which is so appealing. Every developer can feel like they're controlling their own destiny and exercising their own creative power - even when they come up with their own standards.

Yet, in many, and I mean MANY (read, almost ALL) other programming languages (if you permit me to compare FileMaker to a programming language), there are conventions (or standards - of which I'm semantically using both words interchangeably). Not to say that FileMaker doesn't have these. In fact, over my many years of working with FileMaker, I've heard of hundreds of attempts to establish a standard for coding in FileMaker. Even FileMaker, Inc. released a white paper in 2005 after FileMaker 7 had been out for a while, where they documented a variety of suggestions. Even still, these suggestions came from many developers, of which each had their own styles of creating a solution - so the white paper read like suggestions instead of conventions or standards.

After attending Pause on Error in Portland, and hearing the number of people "claiming" they wanted such standards, I decided to start to do this for myself - knowing that decision by community is a slower process. While working on my upcoming product release called the Theme Studio, I spent a good deal of time focusing on making the code within the solution as readable as possible. The goal was the ability for any developer to be able to open the solution (even though it's a closed solution) and understand. Hence, I'm calling this the "open and understand" initiative.

This meant many iterations where I would head back into scripts and calcs which I had completed months prior. If I couldn't immediately understand my own code then I rewrote it. If something was extraneous, I cut it. Finally, after doing this for about a year, I sat down and created documentation about my own conventions. I then decided to release it to the public.

While not fully complete, what I've started is documentation for others to follow - and contribute to. I have no illusions that what I've documented will become the single standard - that's the dream world where we have "one" OS, "one" web browser and many other "one's" which makes it easy to do seemingly simple things, like create one css style sheet instead of 2 or 3, or be able to pick up a FileMaker solution and easily figure out what the heck is going on.

If collaborating on, and leveraging a set of standards, which frees you from the confusion of a database without order, sounds interesting, then this video should give you and idea of what I've started. My approach is one of openness. While some of what I've documented will stay the same, some of it will change based on input from the wealth of knowledge and experience which extends beyond my own. One final thing I found interesting while researching standards was the opening section of the Java Code Conventions document from 1997.

  • 80% of the lifetime cost of a piece of software goes to maintenance.
  • Hardly any software is maintained for its whole life by the original author.
  • Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly.
  • If you ship your source code as a product, you need to make sure it is as well packaged and clean as any other product you create.

Enjoy the video and if so compelled, join in. Let's create something useful that benefits those who adopt it!


What is safe to change in an existing solution

I couldn't find a suitable place on the wiki for this comment so I'll post here.

I realise that conventions should be adhered to from the start of a project and often it is best to start from scratch with a new plan than try to remedy a sprawling developed-over-time solution.

However, if I can I would like to clean up an existing solution to be more readable and coherent as I learn more about FileMaker development.

My questions are these.
What is safe to rename / change ?
What does FileMaker keep track of to allow changing without breaking a solution?
What areas should you be cautious about?

(btw, Thank you for being generous with your time and knowledge to the wider FM community, it certainly has helped me a lot)

Things are very easy to change in FileMaker

Because FileMaker provides a good degree of abstraction to start with, you can pretty much take the standards discussed at and modify your solution.

The only times you really need to worry is when you have hard-coded literal values into your solution. For example, if you use something like Get ( LayoutName ) = "Some Layout Name" and then you rename "Some Layout Name" to "Another Layout Name" then you've broken your code.

Otherwise, the ability to simply rename things is one of FileMaker's biggest advantages. It's very flexible that way.

Even with my own solutions, I've simply made a copy and then started renaming to fit the standards we are evolving.

Also, leaving a comment on the standards wiki is simply a matter of clicking the + Add button and choosing to add a comment.

Thanks for the kudos!

By Matt Petrowsky

Conventions Text

I clicked on your "Coding Conventions Web Site" but it could not be found. I'd like very much to get a copy of your Conventions text. Has the web site been moved or how can I get a copy? Thanks.