FMPerception’s realtime developer intelligence is essential for developing. We’ve mentioned that many times. But it’s also good for talking with others about systems and about development practice. Let’s listen in on a FileMaker code review run by a MENTOR with her MENTEE using FMPerception.
———-
INT. Day. MENTOR’S computer. She starts up the meeting. MENTEE Joins.
MENTOR: Hello?
MENTEE: Hey there.
MENTOR: How was your weekend?
MENTEE: Oh it was fine. Spent most of the weekend studying for my certification test. It’s coming up soon.
MENTOR: Ah yes. Well we can chat about that if you want later, but first let’s do some FileMaker code review using FMPerception on your latest project.
MENTEE: Sounds good. I look forward to it
FMPerception in a FileMaker code review
MENTOR: This morning I ran a DDR and loaded it into FMPerception to–
MENTEE: When did you run it? I was working on it this morning.
MENTOR: Oh. Ok. Well let me run the DDR again and load it into FMPerception again. Should just take a few moments. In the meantime, I’ll share my screen. There. Can you see my screen?
MENTEE: Yep. Woo. FMPerception already loaded the DDR. That’s pretty quick. It took like five seconds.
MENTOR: It really is. I use this probably twenty times a day to analyze the files I’m working on and look for something like a script or variable or whatever.
MENTEE: Cool. I should use it more.
MENTOR: Yeah. It’s useful for a developer. Okay. So now it’s loaded I want to review a few things with you. First did you have any questions about your file or specific scripts or workflows?
MENTEE: Well I did want to ask about script and layout organization. I’ve not been putting them into folders and wanted to know what you thought about that. And, um, I’m not sure what else.
MENTOR: That’s okay. We will take a look at your folder structure in a bit. Let’s turn to FMPerception and your file.
Report card
MENTOR: In the FMPerception report I pulled up earlier I noticed a few things and wanted to mention those. First, the Report Card for the file shows a lot of good information. This report, as it says next to the name is slow, but the slowness is just a matter of a few more seconds than the rest of FMPerception.
MENTOR: Here it is. What I notice first is that across the top you’ve got 156 unreferenced and 256 broken references. That’s quite a lot. We should probably get those numbers down. Broken refs could disrupt the intended workings of the file, and unreferenced just might be making the file bigger than it needs to be.
MENTEE: That’s a lot of broken references.
MENTOR: Well it could be many things. When I ran the DDR it was missing a few files.
MENTEE: Yah. Those were taken down temporarily while Fred works on those.
MENTOR: Okay. And as I review the broken references details I see a lot of them, about half, are <function missing>. I must not have the plugin. So no big deal. Others, like “Empty Layout Reference” might need some fixing.
MENTEE: Got it. That’s useful. I wouldn’t have known where to find the broken references. FMPerception shows them pretty well.
MENTOR: It looks like some of the scripts are missing all their tables.
MENTEE: Oh yeah. I imported that script and haven’t finished setting up the references. I keep forgetting that I should import the table first, then the script.
MENTOR: Doing that would resolve the links. You could simply delete this script, copy the table from your sample file to this file and then paste the script back in.
MENTEE: I’ll do that.
Global variables
MENTOR: Moving on. I wanted to review your use of variables. You’re using only a handful of global variables. Global variables are fine to use; they just get tough to trace sometimes when they’re set or used in many parts of the file. Luckily we can see the information here and click on any number to take a look at the details. I can click on “Impacted Layout Objects” and see, in your case, the six items that are affected by a global variable.
MENTEE: Should I not be using global variables?
MENTOR: I think it’s fine to use them. Just be aware of them. I wouldn’t use them to store any security-related information, but otherwise they’re fine.
MENTEE: I don’t follow.
MENTOR: Many developers use global variables to store certain privilege information or other settings. If many of the scripts in the same file have logic in them that depends on the values in the global variables, it would be very tough to track all those down. FMPerception shows you everywhere your global variables are used so you can better track those down.
MENTEE: Okay. So use global variables, and use FMPerception to keep tabs on them.
MENTOR: Yep.
MENTEE: Okay.
Standard script steps
MENTOR: I poked around in other areas of your file. The “Standard Scripts Steps” section of FMPerception. What do you notice about this report?
MENTEE: Hmm. You clicked on “Set Variable” of my Clients file. On the right and in the pane below I can see all the times that is used. I can see the details of the step and its script name and even the line number.
MENTOR: What else?
MENTEE: What’s that “Button” designation?
MENTOR: That’s shows every time the Set Variable step is used in a single-step button.
MENTEE: Oh yeah. Wow. That’s cool. I can see here I’ve got three buttons that perform this step. I wonder if I should turn those into scripts…
MENTOR: I would. It’s certainly harder to debug or change these steps.
MENTEE: I’ll get on it.
Single step buttons
MENTOR: You can use the “Single Step Buttons” line on the report card to track down all of the buttons that do a single step and update those. This section shows you: (1) the layout this single-step button it is on, and (2) the coordinates and region it is located. You may want to review the steps beforehand. If many buttons do the same thing, such as “Delete Record/Request” (3), you can create a script that does that one step and assign the script to many buttons. This report shows a lot more buttons that perform single steps. Use it to eventually clean those up.
MENTEE: Got it.
Standard Functions
MENTOR: Moving on. The Standard Functions area is similar in reporting. Here we can see all the uses of each of the standard functions. Like the Standard Steps, this section shows only those functions you’ve used in the file. You can use the Search bar to find any function you’d like.
MENTEE: I like this. Oh. I can use it to look up my uses of ExecuteSQL.
MENTOR: That’s right. You can see the count here, click on the function and see all the places it is used.
ExecuteSQL()
MENTOR: What’s more, FMPerception treats ExecuteSQL specially. This function is a common performance-issue creator, so FMPerception has a special column just for that when you view all the script steps. The dot here in the row indicates this step uses the function. After sorting by the ExecuteSQL() column and all the steps that use this function are sorted to the top, I can look through each one. So far you’ve only used the function one time.
MENTEE: Ah. Interesting. I like using ExecuteSQL.
MENTOR: It’s useful but can cause issues in performance, so use it, but be aware of each use and any implications. And, of course, there are many other ways to get the same result. FMPerception has this separate ExecuteSQL() column in many sections: Scripts (flat), Steps (flat), Layouts (flat), Layout Objects, Table fields, calculations and other places where ExecuteSQL could be used.
MENTEE: My first DevCon was in 2012.. I clearly remember sitting in the audience by myself and listening to one of the presentations. ExecuteSQL had just been introduced and the presenter was gushing over the fact that he was able to reduce the number of table occurrences by a huge percentage using ExecuteSQL. Everyone applauded. There were gasps.
MENTOR: I remember that. ExecuteSQL is great, but its performance considerations are worthy of thought. In most cases adding a table occurrence and relationship, if you keep the graph organized, is less of a performance impact than using ExecuteSQL in the wrong place. I’m finding I use ExecuteSQL less and less. There are other ways to get the data I need.
MENTEE: I like using ExecuteSQL, but will explore other ways to return lists.
Take a break
MENTOR: Great. Hey. Can we continue in just a few moments? I have to step away. Let’s connect again in 15 minutes. Okay?
MENTEE: Okay. Sounds good. Talk in a few.
END SCENE
Realtime developer intelligence code review
The mentor and mentee took a break. We’ll get back into their conversation in the next post. As you can see in this first half, however, FMPerception is useful in a code review. The conversation centers around objective facts found in the intelligence tool. The mentor can spot bottlenecks or potential issues, and the mentee can use the facts to improve his code.
Let’s get back to the FMPerception FileMaker code review in the next post.