FileMaker Custom Function naming conventions

[tonywhitelive]

I sometimes name FileMaker Custom Functions with a special character prefix so that when I see them in calculations there is a visual difference from:

• $vars
• $$vars
• ~ (Let Function variables)
• Table Occurrence Names
• Field Names
• Built in FileMaker Functions
• Plugin functions (which notably use prefixes as well)

As far as I know, FileMaker Custom Functions are not called by external technologies and therefore we can safely use characters in the name that we would want to avoid in, for example, Script Names, Field Names, etc.

Using a prefix also facilitates type ahead as a single keystroke separates Custom Functions from built in FileMaker Functions

I have been using the following 3 conventions:
[1] #
[2] @ // even though Brian Dunning's free FileMaker Custom Functions library does not seem to like @ as a prefix (search for @escapeTextForFind_v4 which will fail and then try FileMaker Custom Function: @escapeTextForFind_v4)
[3] lower case because built in FileMaker functions are upper case

I avoid _ as a prefix because it is used so many other places that it does not visually stand out.

What other prefixes are people using?
Seems like `, !, and % are allowed and on the keyboard.

Thoughts?

[ByteTheBullet]

I typically use # as a prefix. Seems to be easy to pick up visually, and it's not a character that is common in any calculations.

[bdbd]

I use prefixes in my custom functioins to create a pseudo-namespace. This helps me better manage the many custom functions I use, both of my own creation and from external sources.

My naming strategy goes like this:

• Start with a two or three character code denoting the authorship (dc for D-Cogit);
• Add a grouping name (my error handling custom functions start with dcError);
• End with two underscore characters to separate the prefix from the function name.

Here is an example: dcError__isError__n. As you can see, I use lower camelcase naming for the function name (one reason for the separator) and a suffix to denote the return type.

[jwilling]

@bdbd

dcError__isError__n

Ah the fabled camel snake!

[Malcolm]

I have to admit that I'm very fond of the camel snake. I think of the snake separators as field separators.

[HuConn]

For my part i have two different syntaxes, one for functions I use very often and one for the rest. I am an old school, low level, software developer, so I have a minimalistic approach that I don't see in most others code examples. (Started with Assembler and Forth in the 1990's).

Anyhow, these screen dumps should be self explanatory, and the naming convention makes it very easy for me to remember. Something that is important for me, since may standard library currently contains 483 custom function.

With the name space approach I can easily spot them in my calculation, and with the "look ahead(?)" i just start typing "num." to see a list of all my functions concerning numerals. (I also use MBS plugin extensively, and love the Syntax colorization).

So first are the often used CF's, and then some random screen shots from the list.
(The parameter "setup" is a map data structure that makes it easy for me to add more options to a them).