A bug free life with ACR: the six ACR categories

Welcome back, captain. May I congratulate you once again on your promotion on being in charge of your ship with ACR as your first mate as you demonstrated courageously in part one of our treasure hunt? On this second quest, we are going to sail the six seas, also known as the ACR categories. Did you conquer them already? Then go quickly to the last part of the journey: overcoming minor, major, critical, and blocking obstacles.

ACR Categories

ACR has six different categories, namely security, performance, reliability, maintainability, architecture, and project hygiene. Referring to your experience as pirate captain, I will explain the different types of ACR rules and their importance in the process of developing a high-quality Mendix application. 

Security

As a professional captain, you know that on every journey you run the risk of encountering (other) pirates who will try to steal your treasure. And not all treasure is silver and gold, mate! You want to make sure that your crew is sufficiently trained to keep those thieves at bay.

In the case of your Mendix application, your most valuable asset you want to protect is its data and functionality. The ACR security rules’ main task is to make sure you won’t forget to close any back doors where a hacker or unauthorized user may slip in. It will tell you if it has found any security issues, potential vulnerabilities, or unsafe dependencies.

Examples of security rules

• Access rules in multi-tenant apps should lead to CurrentUser;
• Published Rest and Web services should require authentication;
• Constants should not be used for sensitive information;
• Microflow called from the client should apply entity access rules.

Reliability

While you are defying stranger tides, you want your ship to be reliable. Imagine the horror if at one point you must climb the crow’s nest to keep your feet dry before docking.

ACR rules in this category often point to buggy code in your application. Buggy code is code that is likely not working as intended. These rules spot patterns that can cause code to fail, are prone to bugs, or as something the user might interpret as a bug like unresponsiveness or unexpected behavior. 

Examples of reliability rules

• Variable CurrentUser should only be used in a user context;
• Expressions for “then” and “else” in an “if” statement should be different;
• Only variables that are not empty should be returned or assigned;
• MM and mm tokens should be used correctly in parse/format date-time functions.

Performance

If you ever find a time machine to the 18^th century and got yourself on the run for British soldiers, you want your ship to be fast. Ideally, you want someone to whisper: “I've heard of one, supposed to be very fast, nigh uncatchable” or shout out “It’s the fastest ship in the Caribbean!”. Therefore, you don’t want that any of your crew members forgot to put up the sail which causes you to slow down.

Coming back to the 21st century, likewise, you don’t want to risk that your users or stakeholders go elsewhere, simply because you don’t deliver the performance they expect from you.

ACR performance rules will be your trusted right hand to keep an eye on any (inefficient) code that could slow down your app.

Examples of performance rules

• Loops should not have loops inside;
• Commits should take place outside of a loop;
• Checking for empty on associations should be done without retrieving;
• Not/or expressions in XPath should be avoided when the path goes over an association.

Maintainability

*Sniffs* - what’s that funny smell? Oh no! It seems like you and your crew members forgot to make sure all the food on the ship will last for a couple of weeks and slowly it has started to rot. To make matters worse, you just found out that even though you clearly instructed that only one type of knot should have been used, that five different knots are circling on deck. What a mess. You can’t even blame the rum.

As you don’t want your ship to stink, you also don’t want smelly code in your application. Smelly code probably does what it should, but it’s hard to maintain. As new features are built, smelly code tends to develop into real issues. Rules in this category point to various code smells if it’s simple to fix.

Examples of maintainability rules

• URL endpoints should not be hard-coded;
• Entity should have a maximum of N access rules;
• Exclusive split should have a descriptive caption;
• Styling should be done using sass.

Architecture

Your ship can’t sail if it falls apart in the first big storm it encounters. Therefore, the architectural elements must be well designed.

The same goes for your application. Like maintainability rules, architecture rules point towards smelly code. The big difference is that these violations require a major refactoring of the app to solve its vulnerabilities.

Examples of architecture rules

• Associations should only rarely be cross-module;
• Microflows should not call themselves;
• Inheritance should be limited to 2 levels;
• Entities should not inherit from a system entity;

Project Hygiene

Finally, as a proud captain, you want your ship to be spotless. You feel your cheeks flush if someone would even think of your ship the Dirty Driftwood instead of the Black Pearl.

Therefore, project hygiene rules are all about the cleanliness of your code, like naming conventions, documentation, folder structure, and so forth. It will be easier to find what you are looking for, you don’t have to bother your colleague what they meant, and it’s just more ecstatic for the eye.

Examples of project hygiene rules

• Entity names should be unique across the project;
• Only folders should be the direct children of a module;
• Layouts should be prefixed properly;
• Large entities should have documentation.

The end game

Wow, I couldn’t have done it any better myself. You’re truly becoming a real pirate with your knowledge about the ACR categories. I think you are up for the last part of our quest: The end game, in which you’ll face a whole bunch of severe violations.