We All Have a World Code View

This blog post exists because you, yes you the FileMaker developer, has both a perspective and opinion about "How things should be done". You have a mental picture of what defines a "standard" when it comes to development. You have either created your own system and methods or you "buy into" using someone else's - either outright or in part. You collect insight as you grow and become a better developer. Along the way your perspective changes.

You may favor code portability over legibility. You may favor being concise over being verbose. You may want your code to be self-documenting over having to create documentation. You may be biased towards zero dependancies (good luck with that in any modern code environment).

Or, you may favor the opposites of any or all of those situations.

To put this bluntly. NONE of them are "right" in their absolute.

For example, in text based coding languages, the fact that some developers like to use 2 spaces, where another may like 4 and yet some will standardize on a tab character means that we all have differing perspectives and coding desires. Sometimes it's chosen. Sometimes it's imposed.

Based on the comments which started on the Empty strings page on this web site, this blog post and the comments serve as a place for open discussion about the notion of "standards" within the world of FileMaker development - hence the topic titled "The Great Null Dilemma".

Defining "Standards"

The definition of standards can be very murky unless clarified and agreed upon. The key point here is "agreed upon" for the benefit of those choosing to adopt said standards. If you're a single developer, there's not much disagreement - because what you say goes.

However, if you perform any degree of work which may be jointly shared, then arriving at an agreed upon set of standards is what promotes collaborative understanding. And a good degree of personal benefit if I may say so myself.

My own personal viewpoint comes from having worked with FileMaker since the mid 90's and also having worked with a variety of content management systems created within PHP. PostNuke, Typo3, Xaraya and Drupal. I've also created many scripts and done work with both PHP and Perl based on using repositories of code, such as CPAN and PEAR.

In most every situation where I've agreed with myself to use someone else's code and take advantage of it, I've had to do a good deal of learning. I had to learn how things worked and why they were done that way. I had to seek to understand. Once I had it, I could take advantage of what I had learned over and over. I am also able to come up to speed quickly on any updates to what I had already learned.

Please note, I didn't have to agree with how they did things, because the advantage to me was leverage. Leverage allows you to arrive at an end result faster than if you didn't have it. In other words. I can take advantage of a PEAR module ( a pre-existing chunk of code which does something pretty specific in PHP ) and save myself the time and hassle of coding it up myself.

I also became familiar with frameworks such as Cake PHP, Code Ignighter and more recently Zend. I also made an investment in really learning the Drupal CMS. Knowing these things does not make me a coding expert, but I do think it gives me a perspective beyond just working with FileMaker.

Having been involved with using Drupal at an early stage I watched the adoption of Drupal increase significantly. From a code perspective, I would like to say that it was solely because it was "good code". Yet you'll find many developers in the PHP world who will say it sucks. "Because it's not OOP", or some other reason (Drupal is actually using more and more OOP code now). My personal opinion for the reasoning behind increased adoption and acceptance of Drupal is because of the documentation. Both within the code and outside. Documentation is the line of communication between what the code does and why it does it that way. It allows another developer to find the understanding necessary for greater leverage.

It was for this reason that I started this web site.

When you have something documented, which can be referenced, it serves as the blueprint for why something works the way it does. Again, you don't have to agree with it if your main objective is leverage.

Everyone is free to write all the code they want. Personally, I don't want to write everything. There's little point - unless I feel like I have an endless amount of time to do so.

The Perspective Difference

Some developers love to sling technical terms around what they do within FileMaker. They like to apply Object Oriented principles to their scripting and how they structure a database. They'll say they've created the coolest FileMaker system based on MVC (Model View Controller). I know, because I've done it. I've had the pride that comes with applying some cool sounding technical term or process to the world of FileMaker development. However, I know they don't really apply. Maybe their premise does, but it's not quite accurate - because FileMaker is not like other coding environments. FileMaker is like FileMaker, just like PHP is like PHP.

The truth is this. Your perspective about your own code is unique to you based on what you've created yourself, what you've adopted from others and how you've done things in the past. Changing to a "new way" of doing things always takes more effort than doing them the way you've always done them. Yet, it's easy to become stagnate and fall behind because you don't evolve with the "rest of the herd".

Inevitably, most developers will think their way is the best. I'll admit this to myself. It bolsters ego and validates what you know. Yet, I must also admit that my perspective is pretty unique - in that I'm the only one who has it.

When it comes to "standards", this is where perspective can be removed from the development equation - if, and ONLY if, you desire it. When a set of standards frees you from having to code everything yourself because you can leverage pre-existing content based on those standards you stand to gain the greatest advantage.

Herein lies "The Great Null Dilemma".

If an agreed upon standard outlines something which clashes against your personal perspective, you end up having to make a decision. Change your ways - or - don't. Stay with the project - or - don't. In the world of PHP frameworks there are plenty. In the world of FileMaker, there are few. The ones that are documented are the ones which exist for consumption - otherwise they exist in obscurity.

The fact that a standard exists does not mean you must use all of it - unless you expect what you create to interconnect with other things created under that same set of rules - and be understood by those who adopt the standard.

As I watched the world of Drupal grow up from 3.6 to 4.7 to 5, 6, 7 and now 8, I've seen every type of "coder" personality. From flexible to inflexible.

Yet despite the personality type, or personal desires regarding the "how" something should be done, there was one thing that kept some of the perspective out and kept the project growing.


Make your Case


That's what this site is about. Documentation about the standards that "we" agree on. If we agree (we being the majority who have adopted) that using an empty custom function named Null does create a dependency, yet that dependency is acceptable because most projects opt for readability and comprehension over portability. Then we let the documentation speak to that fact.

If our concern is greater adoption of the standard, because that validates our own work and efforts, and portability is a higher priority, then it's quite obvious that we kill the empty custom Null function.

Regardless of whether you agree with everything, some things or nothing here, if leverage is your objective, and you've obviously got a stake in the game - then make your case. Show, why you feel the way you do and convince others of what you say. Group participation and documentation is what makes for a good set of standards.

Hopefully, the content you find on this site will ultimately benefit your choice to continue to work with the FileMaker platform. Whether you adopt or not. If you do choose to use these standards then participate. Just don't expect that "these" standards will be "your" standards - they may not be.

So, let's open the debate and create something that helps those of us who are here.

We can't be all things to all people - lets not try to. It's really hard - and tiring.


  • No labels


  1. Hey Matt, I don't doubt for one minute that what you are doing has value to those of you who choose to follow it. Its also clear that the majority of the people here don't place the emphasis on portability that I do.  I understand that. What I am proposing is new and quite frankly unproven in the wider market.  So it's OK. Go for it.

    I am going to go off in search of a less tightly coupled, more modular  approach to building FileMaker solutions. Notice I didn't say one with zero dependencies and perfectly modular, just less tightly coupled, and more modular.

    We will see how far I get.

  2. For the benefit of the FM community...Todd,can I request you continue to present your ideas here.  I am probably in the middle of where you, Matt, and Jeremy stand.

    Not being so tightly coupled is mentioned a few times in the standards. So that is entirely part of the process.  There are a few things here that I don't see the benefit of the approach we have moved toward.  That said, I haven't had a better example of some of it.  So I personally haven't commented much on them yet.

    This Null Custom Function has raised an interesting discussion. And I don't see the issue being the use of the NULL at the root of the debate. I agree with avoiding unnecessary dependencies.  But at the same time, not having it in a solution and having to diagnose the issue only happens 1x for any given file.  So the speed of development and troubleshooting comes back to is the CF worth it to improve speed? And does it degrade the quality of the code? CSS in web design is a good example of dependency that IMPROVES the quality of the code.  The stylesheet is required for the webpage to render correctly.  Can the visual identification of spotting the word NULL, improve the quality of the code? I suppose everyone will have a different idea about that.  Here are some of the factors that tell me if it's worth it...it involves Dev time, readability, dependency cost, debuging hassle.

    So for this example, I'll run my thought process...which I use with every change in my coding approach.

    Using ""

    Portable, but readability is limited. While this is the built-in code for FM, it can be tricky to spot in a long calculation. Especially in areas where you have to quote out literal text.  But it's easy, for sure.

    • Time spent diagnosing why it works in Solution A and not Solution B: None
    • Characters to use: 2
    • Time spent Implementing into code: How long does it take to type?
    • Time spent looking for it in the code: ???
    • Functions as expected without too much digging: Yes

    Using /* Null */ ""

    Readable, portable.  And frustrating to type more than once.

    • Time spent diagnosing why it works in Solution A and not Solution B: As long as it takes to remember the syntax
    • Characters to use: 13 ( including spaces )
    • Time spent Implementing into code: Roughly 6x as long as "".
    • Time spent looking for it in the code: Less time than "", it jumps out.
    • Functions as expected without too much digging: Yes

    Using NULL as a custom function

    Readable, portability is dependent on the CF. 

    • Time spent diagnosing why it works in Solution A and not Solution B: Copy / Past CF = 5 secs if you didn't have it in a template file already
    • Characters to use: 4
    • Time spent Implementing into code: 2x as long as ""
    • Time spent looking for it in the code: Again, easy to spot
    • Functions as expected without too much digging: Yes

  3. Hey Josh

    CSS in web design is a good example of dependency that IMPROVES the quality of the code.

    Its not about removing all dependancies. Its about have as few as them as necessary, and perhaps more importantly making those dependancies clear. Every HTML file declares it style sheets quite clearly at the top of the file. Its very clear.  But take inline styles in your HTML as another example.  This is considered a bad practice. Why, because it spreads your dependancies all over the file. They are not clearly defined.  .  But it sure is easier just to throw a little style on the element, rather then have to figure out which stylesheet to put it in and get the cascading rules right.  Both of these solutions use CSS, but one way is bad, the other is good. 

    We have to recognize that everything you add to a FileMaker solution or any solution comes with a cost. FileMaker has very poor organizational tools, so you are often forced to look at far too much information at  a time. The custom function list is a good example. The graph is another. Having tons and tons of stuff in there increases the cognitive load on the developer. Throwing another custom function just because its easy and fast doesn't make it the right solution.

    Another example is $$Variables. These are bad news. Are they easy and fast, yes? Are they always the best solution, No. This is not just true in FileMaker.  Take JavaScript or php as examples.  Both of them have global variables, and they are despised by most experienced programmers. Is it fast and easy to global variables in either of these languages. YES, Is it a good idea, NO

    For the benefit of the FM community...Todd,can I request you continue to present your ideas here.

    I think I need to go elsewhere and work on this for a bit.  I need to be able to show why it makes sense to give up short term gains, like CFs and Global variables to make even larger long term gains.  So far my arguments have been just that arguments. I think it needs to get much more practical.  I need to release some Code. But I am not quite ready to do that. In three weeks I will be presenting what I have so far to a group of Devs at Pause On Error, I will be looking for feedback and input and other ideas that might help move the art of FM modularity forward.  After that I may be ready to put something out there.

    Thanks for your encouragement

  4. So I got some good feedback and lots of encouragement from people at Pause.  I thought I would just update where I stand on all this as of today.  I launched a web site with the specification and the first couple of modules. Its a work in progress and I haven't announced it yet. I will make a public announcement in the coming weeks.


    Let me say that I do not think that this is a competing standard at all. The focus is completely different.  Modular FileMaker is about writing modules, small loosely coupled code bits.  FMStandards is about writing solutions. These are very different things. By necessity they will require very different practices. Things that you would do while coding inside a module you would not to when coding out side of one and vice versa. There a few areas where there is unavoidable overlap and in those areas I hope to spell out practices that are compatible with this or any standard, if possible.

    I have about another 8 or ten modules I want to publish and several devs have offered to contribute as well.  Later in the summer I will get a chance to a present all this at DevCon. By then I hope to have lots of modules and a fairly stable spec.

    If your interested please take a look and leave comments on the site.  If you want to get involved or write a module let me know and I will get you setup with an account on the site.


    1. Thanks so much for the contribution to the community. Based on what you showed and talked about at Portland POE 2013, I'm sure there are many things we'll be integrating into our standards here.

      As was pointed out when we had talked at Pause and via many comments here. My personal sense is that filemakerstandards.org is not a monolithic attempt at corralling as many developers into some drummed up methods of coding in FileMaker. Our impositions regarding style and format are here to promote clarity and easier understanding of FileMaker code. While I TOTALLY enjoy a reduced number of dependancies for any amount of code to be copied and pasted. I still value being able to understand (in particular - easily read) the logic of something.

      I look forward to going through the code you have on your new site and I imagine your methods of walking array data will show up as a page on this site.  Would you like to be the initial author of it here? I'm sure the community would love to see your graphs about the scalability and the logic behind why FileMaker duplicates immutable strings.

  5. Hey Matt,

    Thanks for contributing to the discussion at pause. (smile) I know you don't like my use of the term "monolithic" in regards to FileMakerStandards, and I'll admit there is a certain amount of hyperbole in the use of that term.  But my main point is that I think there is a lot to be gained by focusing on smaller, well built, well tested, and reasonably portable modules, even if that means sacrificing some amount of readability inside of modules

    However I do think that someone could take the standards here and use them to assemble a solution out of Modular FileMaker modules, especially if we can document those few areas that need to agree.

    I will be posting about the HyperList very soon. And I would be happy to see it posted over here as well.  The code is available right now at modularfilemaker.org.  if anyone wants play with it.