ISO FileMaker Magazine: FileMaker Video Tutorials, Templates, Help & More

by Matt Petrowsky

Article options

• Watch Full Version
• Download Movie File
• Coding Conventions Web Site

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!