• Use a single space between function name and opening parenthesis as well as between separating semicolons and within parentheses.
    This facilitates easy selections within both Windows and Macintosh when double-clicking to highlight

    Function Name ( with ; parameters )

    good

    Function Name(with; parameters)

    bad

  • Do not use a space at the end of lines of code closed by the semicolon.

    Let ( [
  ~replaced = Substitute ( FunctionalArea » Tablename::fieldName ; "foo" ; "bar" );
  ~anotherVar = "literal string"
];
  ~replaced & ~anotherVar
)

    good

    Let ( [
  ~replaced = Substitute ( FunctionalArea » Tablename::fieldName ; "foo" ; "bar" ) ;
  ~anotherVar = "literal string"
] ;
  ~replaced & ~anotherVar
)

    bad

  • Empty or no-parameter based custom functions can take the optional opening and closing parentheses despite FileMaker's ability to accept calculation code without them. Doing so does increase readability and enforces proper syntax checking by FileMaker when a similarly named variable, global or field may conflict.
    Note: certain custom functions, such as Null are Reserved elements and do not need to follow this convention.

    Let ( ~something = FunctionName () ; ~something )

    good

    Let ( ~something = FunctionName ; ~something )

    acceptable

Single platform development

In order to stay cross-platform compatible with regards to code editing, the space on either side of the semicolon facilitates easier parameter selection using the mouse. However, if you are working within a team of developers or all developers are working on the Macintosh, it is acceptable to remove the space between the parameter and the semicolon. This increases readability, but does force the developer to be familiar with using keyboard selection strategies, such as advancing to the next word and using the arrow keys an shift to navigate and select text.

  • No labels

18 Comments

  1. Anonymous

    Agree with space for parentheses.

    Disagree that space before separator is bad, I prefer the space.

    BTW, "it's" with an apostrophe means "it is." You've made this error on several pages where you meant "its" (no apostrophe).

    It's all about standards, after all. :)

    1. Matt Petrowsky

      Thanks, I'll fix the "it'ses" where I can. (smile)

      The intention behind removing the space is that when reading normal text, we're used to the space. By removing the space before the semicolon, this facilitates faster, more normal reading of code.

      However, as indicated, that one is suggested as optional.

      1. Anonymous

        Actually, the issue comes down to editing across different platforms. If I double click a parameter on a Mac, it ignores punctuation. On Windows it picks up the trailing semi-colon. Just irritating! I therefore believe you need the spaces to make replacing arguments easier.

        dd @ dyce dot com

        1. Matt Petrowsky

          Yep, I'll go with that. I opened up my Win 7 copy and find that as a standard, it's best to go with the extra space.

          I'm not fond of it myself because I'm a keyboard user and rarely mouse, but in the interest of keeping things consistent I agree. I changed the suggestion and also added the trailing semicolon item.

  2. Anonymous

    I do not like the space between function name and open bracket. And I have to reasons to skip that space:

    1. The function parameters are a direct part of the function; function name and parameter should be considered as one unit. Also, round brackets are used to define syntactic structure of expressions, overriding precedence: 2 * ( 3 + 4 ). Placing the open bracket right after the function name will distinguish between these cases.
    2. To distinguish between function names and parameter and field names I often add empty round brackets behind functions without function parameters. This will enhance readability.

    The following code is clearly a function call:

     UUID()

    Without the bracket it could be a field name or parameter name:

     UUID

    1. Anonymous

      Sorry, forgot to sign:

      Arnold Kegebein

    2. Jeremy Bante

      Function names are already distinguished from other elements by being UpperCamelCase. The only element that might be confused via case is a Tablename, which will always be followed by a double colon "::". Parameters and non-global fields are both lowerCamelCase. This particular example is more tricky, since an acronym (well, initialism, anyway) FunctionName could be confused with a GLOBALFIELD, especially if that function doesn't take any parameters. In terms of ease of use and readability, I could be fine either way. That leaves me with the "What would FileMaker Do" principle, and FileMaker does use the separating space when you double-click on a function in the calculation dialog.

      1. Matt Petrowsky

        RGB ( red ; green ; blue )

        Is a good example of an UPPERCASE function. It does have parameters, where UUID might not - depending on implementation.

      2. Anonymous

        Actual, I have to disagree. What about simple variables, such as (custom) function parameters or variable declared with Let (not talking about $localVars and $$GLOBAL_VARS)?

        The use of brackets will distinguish between functions and simple variables. It will also add the advantage of internal syntax checking.

        Let( [
    UUID = 0
];
    UUID
)

        This code will raise no error. The expression will return: 0.

        Let( [
    UUID = 0
];
    UUID()
)

        On the other side, this code will raise an error message: "An operator (e.g. +, -, *, …) is expected here.". If I actual wanted to return an UUID (with a custom function), but made an typing error when I created a simple variable UUID. The added bracket will save me some debugging time because of FileMaker's internal syntax checking.

        Okay, this example is very simple and the error obviously, but I guess, you get the picture.

        Arnold Kegebein

        1. Matt Petrowsky

          I can understand the reasoning behind your suggestion. I would opt to make this an optional item within the standard as a tip or suggestion.

          My hope would be that an astute developer would never mix similar name use and I understand the example, but I would think that a developer would always work to avoid confusion.

          I personally may adopt enforcing the use of () on empty parameter function, but I also see the likely hood of positive recognition of those custom functions which are all UPPERCASE. I'll add the tip and make note of the obvious syntax checking.

        2. Jeremy Bante

          The existing standard for naming local variables in Let() statements already addresses this confusion. Assuming you never prefix anything outside a Let() statement with "var.", there will never be a collision:

           Let ( [
	var.UUID = 0
];
	UUID
)

          This calculation clearly returns a new UUID, not 0.

          1. Matt Petrowsky

            Totally correct Jeremy. I did add the suggestion as optional within the standard. Most of the time I'll probably go without, but I have tried the empty parens on some development today and it does seem to help in some cases.

            I don't think providing it as an option makes the code less clear - do you? It just means that, when used, a developer will have to accustom themselves to seeing the empty parens as an indicator of function use. I asked myself if it would bother me if I saw it witin a solution and it didn't seem so.

    3. Matt Petrowsky

      I don't know if setting the use of () on non-parameter custom functions should be part of the standards. This seems like a personal preference which doesn't have too much impact.

      I say it doesn't have too much impact, because the number of UPPERCAPSCUSTOMFUNCTIONS will be pretty low - and in most cases, they'll likely be pretty evident as to what they are.

      The space between the FunctionName and parens is something where we're going to follow FileMaker's lead. I personally prefer to not have the space because it's closer to other languages, but it's not cross-platform compatible - as is why we're going with FileMaker's existing standard.

      1. Anonymous

        Okay, I understand your argument to follow FileMaker's lead.

        It's quite funny, almost all my external functions (from plug-ins for FileMaker) have no space between function name and open bracket. It looks like plug-in developers have their kind of coding standard and FileMaker is doing a different thing.

        Arnold Kegebein

  3. Anonymous

    Naming of Parameters in Custom Functions

    For my own custom function I use an underscore in front of the parameter name. The parameter name itself uses lowerCamelCase.

    MyCustomFunction ( _parameter; _anotherParameter )

    The reasons why I name them this way:

    • The underscore helps to identify them as a custom function when displayed in a FileMaker function list.
      In the past I also used lowerCamelCase for the function name ( myFunction( … ) ) to separate them from FileMaker functions, but following the coding standard here I consider changing the names to UpperCamelCase.
    • Some simple names (like Char, List, Min, Max, …) are already used for FileMaker functions and cannot be used for parameter names. Instead of renaming the parameter into MyChar, MyList, … I simply use the underscore. This allows readability without obscure or misguiding parameter names.
    • Local variables ($var) and global variables ($$VAR) have already a prefix. I like to give my simple variables (defined with Let() or per function parameter) a prefix as well.

    1. Anonymous

      Darn, forgot to sign again. ;-)

      Arnold Kegebein

      1. Anonymous

        Why don't you just Log In, so your comments will be signed?

        Why don't I also?

  4. Anonymous

    I understand why it's suggested to add parentheses even if a function takes no parameters, but I want to point out that this contradicts FMI's own practice and explicit recommendation. Here's a quote from their FMA Development Manual:

    If you are creating a FileMaker plug-in with functions that do not require any parameters, make sure the function “prototype” registered for that function does not include parentheses. For example, “DoThis” should be registered instead of “DoThis( )” as the function prototype.

    Mikhail Edoshin