I think that many of you are familiar with this topic, but I’ve received today a question related to AL code analysis and I think that also a response here can be helpful.
Every Dynamics 365 Business Central developer now knows for sure that in AL you can activate code analyzers for inspecting your code. You can have more info here and here. AL Code analyzers are the following:
- CodeCop is an analyzer that enforces the official AL Coding Guidelines.
- PerTenantExtensionCop is an analyzer that enforces rules that must be respected by extensions meant to be installed for individual tenants.
- AppSourceCop is an analyzer that enforces rules that must be respected by extensions meant to be published to Microsoft AppSource.
- UICop is an analyzer that enforces rules that must be respected by extensions meant to customize the Web Client.
Every company has its own practices for inspecting its codebase. There are companies that never uses code analyzers, there are companies that activate some of them on every compilation and there are companies that activate always all the code analyzers on every project.
What’s the best way of work? Someone can answer by saying “activate all analyzers to have a 100% code clean” but there are practical situations where this is not possible or extremely time-consuming to be activated immediately. A tipical example that I see on many partners is the following: they convert a big C/AL solution to AL by using the txt2AL tool. Some objects are refactored in AL but some objects are a pure conversion from C/AL. The txt2AL tol during code conversion creates a full working AL code but that does not respect the formal standard of AL (for example, code conversion creates FINDSET instead of FindSet() and this is a warning for CodeCop).
What happens now? The partners activates all the AL code analyzers and from 0 errors the solution goes to hundreds of errors.
In these situations, I think that can be useful to know that you can customize the code rules that comes in the standard code analyzers by creating custom rulesets.
As an example, consider the extension that I’ve used in my previous post. I have 0 errors and the extension is fully working. But if I activate for example the CodeCop analyzer, this is what happens:
A number of warning appears. This is because my code does not respect all the official AL code style guidelines. What can you do now? You can essentyally do the following:
- Deactivate the CodeCop analyzer or ignore all the warnings 🙂
- Fix some warnings and ignore the others
- Create your custom rules
Point 3 is what we want to do now 🙂 We don’t want to ignore the AL coding guidelines (because we want a very clean code) but some rules are too crazy for us (and believe me that some of them are crazy) and so we want to create our custom rulesets.
A ruleset can be created by adding a file called <name>.ruleset.json (where name is the name of the ruleset) and using the truleset snippet.
Here as an example I want to create some custom rules for my project where (see the first image) rule AA0074 and AA0214 are ignored, while AA0008 for me has a severity of error instead of warning. The ruleset can be defined as follows (use the trule snipper to create a rule):
After creating the ruleset, you need to enable it in the settings by adding the al.ruleSetPath clause as follows (points to the location of your ruleset file):
What happens now to your AL extension? Magically, error rules are changed and in my example now I have 1 error and 2 warnings:
I think that having custom rulesets for company is really useful because you can guide your developers on how they should write code. Here we have created a ruleset for a specific project, but in a ruleset you can also integrate a company wide ruleset to custom rules per project. To do so, just add the following declaration to your ruleset file and point to the company ruleset:
Rulsets can help you on writing code clean without become too much crazy, so remember that they exists 🙂