In some programming languages there are either functions or named variables which are created/declared for purely temporary purposes. These "placeholders", while temporary and often required, have little directly applicable relevance to the core functionality of a given FileMaker calculation or script. The most common of these situations is an Evaluate () function which declares a variable variable itself.

The suggested best practice is to use the Reserved elements character of an exclamation point (!) as the "throw away" or "non relevant" declaration of such elements. The following list are some of the possible variations.

$! = Evaluate ( "Some FileMaker calculation here" )

! = "calculation scoped unnamed variable"

!trash = "calculation scoped named variable" // keyword 'trash' is adopted by this solution

The exclamation is reserved, but any other keyword (optional or otherwise) is up to the developer. The exclamation, in the context of these standards, essentially means "you can safely ignore this".

Here is some sample code.

Let ( [
$variableVar = "fooBar";
~evalString = "Let ( $" & $variableVar & "=" & Quote ( "baz" ) & "; True )";
! = Evaluate ( ~evalString )
  • No labels


  1. The title may need to be changed to something else if "Non Relevant" is not understood. It could be titled Temporary Placeholders or something else. $ignoreMe just doesn't work for me and it would be nice for us to standardize on something we all agree on other than $void. (wink)

  2. Also, while thinking about it. If $ignored is something that might be used in the case of a filter, then maybe we go with something closer to the familiar OS terminology. Like $tmp. Does everyone know /tmp is temporary? Or how about making it language independent? $` (back tick) or $' (single quote) or $– or $— (em or en dash) Not self explanatory, but easy to spot in code.

  3. Another sigil-type possibility is $~. I figure such use might expand its interpretation from just "private" to the more vague (and, in FileMaker, more technically accurate) "don't look behind the curtain."

    1. Given the discussion going on over here: Reserved elements, I agree with the use of a tilde "~" as the name of a variable to ignore.

      1. The problem I'm having with the ~ (tilde) as the "ignored" variable is that it has an implied meaning in our standards. My logic works out as as follows.

        ~ = private = may be something you need to pay attention to in order to understand the operation of something

        ! = ignore this = you absolutely don't need to apply any mental thought to this because it serves no real purpose (other than evaluation)

        The exclamation would enter the Reserved elements section under that meaning.

        It would adopt a similar convention as $~privateVar and $$~PRIVATE.GLOBAL and take on the meaning of $!ignoredVar and $$!IGNORED.GLOBALVAR.

        As mentioned by Jeremy, we probably don't want to dilute the "private" scope into something more vague.

        1. I thought the "private" ("managed"?) scope is already diluted into something different by using it in variables where it can't precisely mean that. "~" still means "you should probably ignore this," just for a different reason than what we're discussing here.

          I think I like $! as a throw-away variable anyway, though. It takes up that much less horizontal space, which is a nice feature for something designed to not distract attention from the code of actual interest while filling-in a syntactically required position.

        2. Yes, I see your point that ~ prefixed variables need to be paid attention to, whereas "non-relevant" variables does not.

          I don't see the need for a global "non-relevant" variable. If the purpose of the variable is to evaluate a calculation then throw away the result, it's use should be restricted to calculation or local scope.

          1. True on global variables. It wouldn't really apply since they persist. (smile)

  4. While working on a technique file today I realized that "!" is not a reserved char.

    How about this?

    Set Variable [$!; Value:VariableToggle ( "$$GLOBAL.VARIABLE" ) ]

    I doubt FileMaker will start using operators such as !=

  5. One methodology I am really starting to like is using self-descriptive names: "Clarity is more important than brevity", as Jeremy Bante puts it. Any single-character variable name is not self-descriptive, so I hesitate to adopt it as a standard.

    I think "ignored" could work, but as you said, that variable name may be useful in the context of a filter. I suppose that same issue could occur with any descriptive name. A prefix and a descriptive name, like "!ignored", could possibly solve this issue.

    As far as using "!", I would be concerned with it being read as "not", which is what it often represents in many other programming languages.

    You mentioned $` (back tick) which is on the same key as ~, which we also use as a prefix. That makes it seem like a logical choice for a new prefix.

    Also, FWIW, I'm kind-of partial to "trash" as the descriptive portion of the variable name. It just seems like the perfect description since we are essentially wanting to throw the value in the trash.

    If everyone agrees with what I've said up to this point, we are left with two options:

    scopeoption 1option 2


    1. It's nice to be so widely attributed — twice in one day on the same page! Clarity is more important than brevity, but perhaps not absolutely so. If I recall, Matt felt that it was worth defining a convention because he found it distracting to read the uses of $ignoreMe in some of my scripting. I was using it a lot. If it is used often enough, perhaps the meaning will be clear enough without self-descriptive text. The # function name doesn't really describe what it does, either, but we seem to be OK with that. Only experience experimenting with both can tell if $! or $`trash is least painful. What I can tell so far is that one self-descriptive name didn't bother me, but it did bother someone else, and trying $! has worked as well for me as $ignoreMe. The single-character name seems like the kind of thing that throws you off the first time you see it, but you never give it a second thought once you understand it the first time, which perhaps is an acceptable compromise.

      1. On the topic of using a character vs. a word or combination, I would opt to bypass the use of a word because as soon as you see it - despite any declared standards - if you're unfamiliar, you must decipher its relevance.

        At least with a single char, we are imposing a forced "learning" of what the char means.

        My goal is far from creating something as terse as Perl - and we're far from even close - but the use of some chars like ! in FileMaker means a developer would have to become familiar with our standards here.

        In the range of balance between self-describing, learned conventions and outright obviousness, I think this is pretty close to being useful for us and easily learnable. I too was a bit concerned about the "not" meaning in other languages. However, having come from PHP, Perl, Java/Groovy and Shell scripting I think we're safe with adopting it use.

        If you've ever written a shell script then you know the following does not imply "not"



        Since FileMaker carries no meaning for ! I can't see a reason for not using it when the use of "ignored", "trash", "void" or "dontPayAnyAttentionToThis" is pretty much the same thing as saying "don't look at the dead rat I'm holding up" - you're going to look anyway.

        1. Here's a pretty clear example of how it becomes a bit easier to read the code as the ! relates to the suggested meaning.

          Let ( [
          $variableVar = "fooBar";
          ~evalString = "Let ( $" & $variableVar & "=" & Quote ( "baz" ) & "; True )";
          ! = Evaluate ( ~evalString )

          According to our definition of !, we would be able to totally ignore the evaluation and focus on the ~evalString. Since != has no meaning in FileMaker, the only thing to worry about is the developer who comes in from other languages and says "What the heck is != without something to the left of the operator?"

          1. The one concern that I am having with the use of symbols is the direction of Web and WAN development. ESS and ExecuteSQL use is growing in leaps and bounds.  And the use of special characters becomes somewhat impossible to use our standards here.

            I like the standards, and the direction we are going. But I'm wondering if we should take into consideration that many web developers would never consider any of the standards from the chaos it causes in the SQL side.

            1. I agree that compatibility with other technologies is worth taking into account. I don't follow the TO naming convention of "Group » Table" in production systems, for example. However, this particular example involves syntax FileMaker will not be sharing with any external technology. Even with the field naming convention, the fields that use non-alphanumeric characters are fields we probably shouldn't be using from the SQL side anyway — which is not to say that more compatible conventions aren't worth considering, only that what we have isn't too bad.

            2. I wouldn't describe the use of any symbols within an encapsulated language as impossible. FileMaker itself will maintain its own garden of code and when exposed as web facing, it will translate. IWP has always done this.

              When it comes to ESS I can see some validity to your thought process. However, I am a big proponent of having dedicated and isolated functionality within a FileMaker solution.

              A good example are the @Developer layouts. The "@" is used because it pushes those layouts to the top of FileMaker's long list of layouts. In solutions with many hundreds of layouts, this is a benefit. However, when using ExecuteSQL against any table, I ALWAYS create a dedicated TO for the purpose of queries. @Customers becomes sqlCustomers for this very reason. Because sqlCustomers has been mentally "broken out" of the "filemaker" part of the system, yet it can still be used within it. In that situation, I feel I've created a differentiation which lends to easier understanding - at least for me it does. External systems would also use this semi-segregated portion of the whole solution. Think in terms of "sub" filemaker standards.

              Yes, the additional TO does add some complexity, based on a sheer increase in the number of things you have to parse/manage, but it's isolated out.

              Striving to have all code in a solution be in a state of "compliant with multiple languages/technologies" is a bit unrealistic and (I feel) prevents us from creating the utmost clarity within a FileMaker solution.

              If I'm going to expose part of my solution to ODBC/JDBC, then I won't be doing things like "Group » Table". I'll create this distinct set of TOs for that dedicated purpose.

              When you have a lot of comingled code and things keep growing and growing, you are almost always inevitably going to end up with a spaghetti system that will be hard to break down.

              A little while back, I got an email from someone who seriously derided me for even considering the idea of calling these "standards". He was adamant that our "lack of consideration" for SQL standards was crazy. My reply was of the nature that when you're working within FileMaker, you're working within FileMaker. We don't ignore SQL. We facilitate its use within FileMaker.

              I suggested that he create an account on the site and create the "SQL side" of FileMaker development standards. I'm convinced this can be done in a fashion where we can have our cake and eat it too. Creating a page titled "SQL Compliance" would be very easy and documenting translation rules is easy too.

              For example, "When exposing a table occurrence named 'Group » Table' to external queries through ODBC/JDBC it is highly suggested that you create a dedicated table occurrence following the same naming conventions minus the special characters used for FileMaker development. 'Group » Table' becomes 'sqlGroupTable'. These portions of your solution, within the Relationship Graph, should be located to the left side along the edge of the graph. Because SQL does not require table occurrences to be connected within the graph, you should collapse them and align them within close proximity to each other in alphabetical order.

              I would much rather push this model then try to say "Heck, yeah, I build FileMaker solutions using SQL, HTML5, Javascript, Java and AppleScript - You just have to figure out how all the pieces fit together after I create it."

              If we document these types of things then the "standards" we have created will be just that. (wink)

              1. I absolutely agree with both of you...

                I was thinking along the lines of documenting those things as well.  In fact, I have been passively trying to recruit a few developers that I know do a ton on the web side with FM.  I think getting a couple more ( and I say more because of know some of us already do a lot on the web side ) to help contribute to marrying the FM side of the standards with the external. It will go a long way in solidifying these standards as a core approach of professional developers while still giving the flexibility that FM is known for.

                I will never post anything here to argue or say 'that's a stupid way of doing that'.  However, I will always throw out the thoughts that come into my head like, "what about this???"...primarily to stimulate a productive discussion.  Kind of like this one.

                1. Totally, cool. Josh and anyone else. Please don't ever think that because I post a long retort that I'm thinking someone is being argumentative. My whole goal with these things is to have a collective where the combined experiences create a better situation for all.

                  I remember bringing in Fabrices ObjectID here and people thinking that internal IDs were reset. I remember not being the one to come up with key/value params and using Mikahl Edoshin's system from way back (of which Jeremy and Dan have literally revolutionized - awesome job guys!). Perren is the one who brought Low impact startup.

                  If we each take ownership of various sections, we end up with a much more robust and well maintained set of standards. Those of you with edit privs on pages should use them as much a you want!

                  1. Perfect.

                    Didn't see it as argumentative at all.  I love when people explain how and WHY they do things.  It makes us all better developers. And for those that haven't thoroughly looked into the standards we have here, it gives them a reason to not just walk away...they can see we have reason for doing it this way and have included much more thought into it than we can possibly post here.

              2. Anonymous

                I don't think the jury is ready to declare you not-crazy (smile) , but I agree with your logic on this entirely.

                --Jonathan Fletcher