Custom Function Rules

In the near future I plan to publish a few articles about some FileMaker custom function sets that are pretty complicated, on the same order of complexity as the AssignParams set I recently wrote about.

With that in mind, my custom functions follow a set of conventions that, rather than reiterate each time, I'll publish here and link to.

  • Every custom function begins with a four letter code indicating it's "namespace" or grouping. devp for developer, scpm for script parameters, etc.
  • Each group has a separator custom function that begins with the same four-letter code, followed by nine underscores, a descriptive name for the group, and enough underscores to provide a sufficient separator, as in devp_____ Developer ___________________________________________________.
  • Working custom functions never have string constants in them. Any string constant gets its own custom function, such as devp.Quote, devp.Return, etc.
  • Custom functions that are constant have their main name begin with the letter "k", as in devp.kQuote, devp.kReturn, etc.
  • Custom functions that are utility recursive custom functions (are never meant to be called by anything other than another custom function) have their main name begin with a tilde, as in dict.~Format, dict.~RemoveSpacing, etc. Generally if you remove the tilde, you'll get the name of the primary custom function that calls the utility recursive custom function, so dict.Format calls dict.~Format.
  • Any time code appears in two custom functions it gets its own custom function. Utility custom functions that were created for this reason have their main name begin with an underscore, as in dict._AddSecondCharIfNeeded.
  • Any time code appears twice within a single custom function, it gets its own calculation variable.
  • Parameters and calculation variables always begin with an underscore and use underscores to separate words, as in _list, _dict or _first_char.
  • Custom functions use CamelCase after the grouping prefix, just like FileMaker's built-in custom functions.
  • Calculation variables that are only used once are fine if they increase the readability of the function.
  • Any custom function that is meant to return a boolean value has its main name begin with Is or Does, as in dict.IsValidArray or dict.DoesContainKey.

 I think that's all the rules. If I think of any more, I'll be sure to amend this article.

Add comment


Security code
Refresh

Search

Products