What is the quality of the Mendix App Store modules? – Part 1

That’s the question we asked ourselves when we got more and more enthusiastic about the ability to check the quality of Mendix models. The solution we used is the Fit Test for Mendix provided by Omnext. The goal of the Fit Test is to analyse the quality of your Mendix applications, both based on ISO 25010 as well as a broad set of Mendix Best Practices & Guidelines with regard to maintainability, performance, security & conventions. Not only does it indicate any violations, but it also tells you where the violations are and how to resolve them. It’s basically an automated peer review that goes through all the nitty-gritty details every time you perform a check. We asked Omnext to do an automated scan on all modules in the Mendix App Store using the SDK and we love to share some of the results.

So what are the things we looked into?

Mendix Best Practices & Guidelines

The Mendix Best Practices & Guidelines are defined together with a lot of Mendix developers and MVP’s (= Most Valuable Professionals). Some are common and simple but often forgotten, others are more complex. It’s a given fact that we are all humans and these errors happen to all of us when we develop and deliver at the speed of light 😉 In total we checked 46 modules that ran on Mendix 6.6 and higher.

Overall score very high

Our first conclusion is that the overall quality of the modules in the App Store is high. Over 90% of the modules has a score of 4 stars (out of 5) or higher. This is high as the average score for software in general 3 stars. The power of model-driven development helps to bring in those high numbers.

We also looked for any blocking violations. An important one is “Avoid commit in before and after commit actions”. On Mendix entities you can have Events (before/after create/commit/delete). These events can help you to keep your model consistent and are often used to do calculations/checks (instead of calculated/microflow attributes). If you commit the same object in an event it will trigger the event again and again and again. Your app will freeze and will get into an infinite loop. So don’t deploy any app with this violation 🙂

Perfectly, none of the modules in the App Store have this blocking violation!

Highest number of violations

A very long list of best practices is checked with the Fit Test. The one with the most violations in the App Store is ‘Avoid commit in loop’. We found that almost a quarter of all modules in the App Store violate this rule, some of them multiple times. In certain cases this can reduce the performance of the affected modules.

Why is this wrong? Well, when you commit items inside a loop it will generate a command to the database to update/create a record. This is potentially a performance killer when you have a big list to iterate. The Fit Test makes you aware where you made this error and explains you can correct this issue by:

Step 1) first create a list

Step 2) add your items in a loop

Step 3) after the loop commit your list.

The result is a better performing microflow and a developer who gained some further knowledge. Great, isn’t it?

This post is the first of a series of blogs about how to improve the quality of Mendix applications. Watch out for the next one where we will tell you more about the other best practices like naming conventions and their advantages. Furthermore we will tell you how you can access the Omnext portal so we can jointly work on even better solutions for all Mendix users.