7 Aug 2025 – See also Another Tip for MBS “Check Variable Names”
If you’re on MacOS, and use the Monkeybread (a.k.a. MBS) plug-in with “check variable names” enabled, you quickly come to appreciate how useful this feature, also known as linting, can be.
For example I recently helped another developer track down a script problem that turned out to be a slight misspelling of a variable name, a misspelling subtle enough that it took us a long time to see it (of course for most of that time we didn’t realize the $var name was the culprit). If he’d had Monkeybread installed and this feature turned on, we’d have saved about 45 minutes. Actually I shouldn’t say “we”… my colleague would have immediately seen the problem and wouldn’t have bothered to contact me.
Here’s how it works: when MBS sees a $var it doesn’t recognize, or a $var that appears before it has been declared, the $var will be flagged in red like so.
Ideally, any time you see an error like this, you don’t ignore it — you know there’s a problem and you need to fix it. However, while this feature works great with explicitly declared $variables (created via Set Variable)…
…it does not recognize implicitly declared $variables (created via some other method), for example…
- As input $vars for Show Custom Dialog
- As the target for many of the “Insert” script steps
- Via Let, either directly or from within a custom function
…and as a result some developers either don’t use MBS linting, or perhaps they do use it but don’t take it completely seriously because it “cries wolf” too often, as per this screen shot.
Well it turns out there’s an easy way to tell MBS about implicit $vars; simply add a comment at the top of your script with the implicit $var names like so.
Note 1: in MBS 15.0 and earlier you need to ensure there is no space between the # and the @ — according to a reliable source this may change in an upcoming version of the plug-in.
Note 2. As per this documentation on the MBS web site, @variable, @parameter, @constant, @param or @const can be used instead of @var if you prefer.
Note 3. You can also place each $var on its own line like so if you wish. (I don’t know why you would; seems like a waste of time and pixels to me but don’t let that stop you if you are so inclined.)
I wrote to Christian at MBS to ask about the multiple $vars on one line feature and he pointed out that you can separate $var names with a comma, e.g,
…and that you can learn more about checking variable names here — https://www.monkeybreadsoftware.com/filemaker/SyntaxColoring/12-Checkvariables.shtml
I use Let to declare multiple variables at once all the time. Often, used as a way of grabbing multiple $vars out of a JSON parameter.
I’ve known about this feature, but I’m hesitant to use it or rely on it. To me it seems like added redundancy and a way to silence what could be a valid error with variable misspellings. If you have your variable misspelled in your Let statement, but have it “correct” in your @var comment… you’ve just moved your problem or hidden it further, rather than solved your problem.
I’d turn on that checkbox on immediately if it actually caught implicitly declared variables. Until then, it’s a ton of extra noise in my script workspace… or worse yet, I now have 2 places to keep track of declaring variables and making sure they both stay current.
Is it just me?
Shawn writes:
Yes! All day every day via a custom function, JSON.KeysToVars (https://filemakerhacks.com/2023/06/25/json-custom-functions-for-fm-part-3/)
The MBS work around isn’t perfect but on balance the benefits outweigh the drawbacks as far as I’m concerned.
Var name checking is now a feature I rely on, and I really miss it when I’m working on a machine where it isn’t available.
It is a shame MBS can’t identify implicitly declared variables, but I happily cut it some slack as it does so much that is valuable. I also use a CF to create variables from JSON script parameters all the time and this tip means I will be using Check Variable Names from now on.
I quite like the idea of a single comment to both document which variables are expected in the script parameter and fix the implicit variable issue. I might use 2 comments; one for mandatory variables in the script parameter and one for optional ones.