• Custom functions: are named in the familiar FileMaker format of TitleCamelCase. It is assumed that distinguishing internal from developer-based custom functions will be evident based on access to the custom function list - so no distinct naming differentiation is used.





  • Custom functions: which are private in nature, meaning they're functions reserved for use by other Custom Functions, those not called directly from within calculation code, are prefixed with the tilde ~.





  • No labels


  1. Anonymous

    In my view, it would make sense to prefix names with some namespace designator. This enables developing and maintaining functions in groups that can be imported in new databases. It makes managing dependencies between custom function more easy. As custom functions will be more widely used and available (cf. Brian Dunnings site) the need for manageabilitiy of CF collections will become more pressing.

    Marco Bommeljé

    1. This convention for custom function names doesn't prohibit prefixes. Some of the suggested custom functions in the Best Practices section of this site do use prefixes, such as TriggersDisable and TriggersEnable. This convention merely doesn't use a delimiter between a prefix and the rest of the function name.

      1. One additional point is that FM already uses the "FOO_" prefixing style for External Functions that are dependent on plugins being installed. If we prefixed native functions in that manner it makes it a bit muddy when scanning names to know if the function has any external plugin requirements or not.

        That being said, maybe this would be an appropriate prefix if a CF makes use of any External Functions to help distinguish requirements without having to open the function code and inspect...hmm.

      2. When we do add something to the Best Practices let's make sure and identify any reserved keywords in the Reserved elements section. I added # and Triggers.

        It will also be our reference for what we've used.