<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=1195114&amp;fmt=gif">
CLEVR Quality
8 October 2020, last update 17 June 2021

Yo Ho, Yo Ho! A bug-free life for me with ACR (Part 3)

Hello captain, can you believe we’ve come this far already on our treasure hunt? In part one of our journey, we saw you stepping into your role as captain with ACR faithfully on your side. In the second part of the quest, you steered both your ship and your Mendix application through the six seas, also known as the ACR categories. Now, we are facing the end game. These are ACR violations that could have different levels of severity. If you have overcome these issues, we can finally put our hands on the treasure. 


Next to sailing the six seas of ACR Categories, another way your first mate ACR can organize the rules and the potential violations, is by severity. These are closely related to the six categories.



Code with blocking violations should not be deployed to a production system. Period. If not, your ship will sink, the app will crash or corrupt data or hackers (pirates) could gain access to the system or its data. For example, a strong password policy needs to be set. A rule with a blocker severity is always connected to a security rule. 


Critical rules must be fixed as soon as possible. Although your ship may sail and your app may run, these violations point to code that is very susceptible to bugs and performance problems and/or has security vulnerabilities. Security, performance, and reliability rules fall into this severity.


Developers should be careful with these violations. These violations will not crash the application but are likely to cause problems if left untreated, such as lower development speed. In rare cases, violations might be real bugs. Performance, reliability, architecture, and maintainability rules can point out major violations.


Your ship and app project will go into the wild without any problems. But remember that you shrunk when someone called your precious Pearl the Dirty Driftwood? To prevent this kind of name-calling, look out for maintainability and project hygiene rules that will help you keep your app bright and shiny.


What shines in my eye? It’s the treasure! It’s within our reach. Can you see it? It’s a bug-free life! It has been my pleasure to take you on this adventure. Before our ways part, I have one last note with you to share:


One last note

Whether you want to sail the six seas or can’t wait to develop brilliant Mendix applications, time spent on peer reviewthat could be outsourced to a tool, might not be time well spent. As we’ve seen, it’s prone to errors, overlooking best practices, repetitive, and may not even your top priority. So, be savvy and get ACR onboard and integrated it into your developing routine.

I mean, you don’t want ACR to say to you:

"This is the day you will always remember as the day you almost caught all the (potential) bugs in your code manually."

Will you? 😉

Esther Vis
Esther is one of the developers of the SMART Digital Factory Tooling set. She believes that one of the best ways to learn and to ensure the quality of your work is to review its content. Because of that, her primary focus is the Application Code Reviewer (ACR). Not only is she involved in maintaining and improving this tool, but she also writes new rules that empower Mendix Developers to build high-quality applications even faster. With a background in history and gender studies, she has an eye for the person behind the technology and she makes sure everyone is included.

No relevant post found