From time to time, we refactor FileMaker code either because:
[1] a new feature have come into existence since the code was written
[2] to correct an code architecture decision made earlier.
Some coding decision are generally accepted as best practice. Others are up for debate.
(Sometimes a refactoring decision is hard to make because of insufficient understanding of the pros and cons.)
Here are some possible refactors (big and small) that come to mind:
Classic Theme to Custom Theme
Fewer Comments (move comments to code)
Grouped Objects (Legacy Buttons) -> FM 12 Buttons
Sort <-> Sort by Field
Zebra Stripes (built in as of FM 13)
Labels -> Placeholder Text
Icons to Glyphs (SVG and PNG)
Custom Functions to local Calc code
A Script with Parameter branches -> individual Scripts in a Script Folder (for example, a Script that touches/opens multiple Files in a big system)
Feel free to add other Refactors that you like to the comments:
@weetbicks added 2 "Refactors" below, and makes a good point that not all refactors are always worth doing on old code and might only apply as new methods on new code.
What do you mean by "Zebra Stripes"? Can you elaborate on that?
In terms of CFs I go the exact other way: eliminating local code by using more CFs in order to centralise the code in one place.
Another ReFactor would be:
Placeholder Text -> Button bars (with calculated labels)
I use them a lot in all possible opportunities like e.g field labels, displayed user info, even as bar graphs or frames to group my UI elements. They are really very handy. There are only 2 known disadvantages:
1.You can not format numbers. I use a special CF to do so.
2. They still behave like a button, even if there is no action linked to it. That means, sometimes you can not leave a field in order to save your entry, just by clicking on a surrounding frame element. You have to find a place in the background, where there is no button bar underneath.
But nevertheless I love button bars.
@cheesus
In such cases I place a rectangle or text frame outside the layout. I give this object the name "target".
Button action instead of nothing is "Go to object "target".
In the end that behaves like a click in the background.
Off topic here: Dual use – I use such a off-layout target object on every layout. With anchoring to the right and bottom. So the background expands always to the full window.
Refactoring the #() functions when sending multiple parameters to JSON is one we continue to do when time allows.
Regarding custom functions, we are designing in modular ways that enable us to lift blocks of code from one solution to another. Since While() became available, we can replace recursive CFs with this. Copying scripts from one system to another is far less likely to break should the target system not have all the CFs of the source system. I can’t remember when we last wrote a CF!
The biggest refactoring task for us will be to replace some of the lengthy legacy TO chains; some date back to over 10 years within our CRM core. A job that currently keeps being put back to the demands of new features within our customer base.
Refactoring the #() functions when sending multiple parameters to JSON is one we continue to do when time allows.
I have thought of writing an AppleScript to be called by a macOS Service to refactor Six Fried Rice (SFR) dictionaries to JSON objects. macOS Services to help write FileMaker code
Regarding custom functions, we are designing in modular ways that enable us to lift blocks of code from one solution to another. Since While() became available, we can replace recursive CFs with this. Copying scripts from one system to another is far less likely to break should the target system not have all the CFs of the source system. I can’t remember when we last wrote a CF!
Good points.
The biggest refactoring task for us will be to replace some of the lengthy legacy TO chains; some date back to over 10 years within our CRM core. A job that currently keeps being put back to the demands of new features within our customer base.
I removed a bunch of TOs that were NOT used to display related data, replacing them with finds against a faceless logic file. Seemed to help, although I did not take the time to measure before and after.
Avoiding relationships that are unnecessary is a big plus. Card windows allow us to go straight to a layout, so they can be called without needing relationship bridges.
I am curious about the difference in overhead between using a value list as a way to bring data into an unrelated table. That is when the value list is based on ID and displays another field. Versus having a relationship and displaying the other field. I've been doing it quite a bit lately as a way to avoid relationships.
[1] move UI calcs+objects to static field in table.
e.g. I like a left portal nav of current table to have a small record summary. And instead of loading the portal row with a bunch of objects — with potential conditional hide/format logic and data formatting — I would rather have a single text field from the parent table.
While it might add some weight to the table, I find the performance improvement is worth it.
Sorry – At the first glance I thought you hadn't realized the blue box. Later I got it: You only want to know what character @rivet used.
And because of all good things come in threes (In Germany we have a saying "Aller guten Dinge sind drei") I thought I could search by myself for a possible character that works on Windows and macOS.
