Some time ago, I wrote a blogpost on how to enable code analysis for AL development. At that point, it was an undocumented feature – not to say, it was an unfinished feature that you could already enable. Since the developer preview March update, it is officially here, and things have somewhat changed – no, not changed, improved! :-).
So, quite necessary to do an update on this, with a little more explanation than the documentation provides.
Besides the explanation on the blogpost, there is also a section on docs: https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-using-code-analysis-tool .
Please bookmark that, as that will probably contain the latest up-to-date information about this topic.
How to enable Code Analysis?
Well, there are now three VSCode Settings you need to take into account:
As you can see, you can do more as I previously talked about. From the settings, you can see we can enable code analysis, (duh…), we can even enable a certain analyzer (later more..), and even change some rules … . Hm, interesting! So in a way, (it seems) we can be quite specific on what we want to enable, and even change/add rules, if necessary. Let’s look into that!
So, the very basic setting would be setting the al.enableCodeAnalysis to true:
Well, this will enable all the analyzers by default. To selectively select the analyzers (there are three as we speak), you can use the al.codeAnalyzers setting, like this:
There are three:
- 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.
Wow! That is just amazing!
One remark though – when I was looking into this (and didn’t find any documentation – just because of my inability to search for stuff), Microsoft made the remark: “You should not have all three of them at the same time because that might give you conflicting diagnostics“. Well, I wasn’t able to run into any conflict – but I’d suggest you to play with it, like I am doing at this moment ;-).
Personally, I think it makes a lot of sense to apply all this as “workspace settings”. Which basically means, my settings.json-file looks like this (depending on the analyzers you want to enable):
And is part of my workspace (it’s being saved in the .vscode-folder of the workspace).
Why I do this, well, I simply want to enable this not only for me, but for everyone that works on this project/workspace. So these settings need to end up in my source control, so that everyone’s source will be analyzed.
Bend the rules
It’s not only a matter of enabling the code analysis tool, you can also somewhat bend the rules. If you for example would like to change a “warning” into an “error” or vica versa .. well .. you can! Here is some more documentation on that:
Let me try to explain this with my own words, as I think you really want to do things like that. Let me give you two examples of warnings that the CodeCop analyzer gives you:
- “You must specify open and close parenthesis after …”: let’s assume I don’t care about this one, and I want the code analyzer to skip this one for my workspace.
- “Variable … is unused in the method …”: let’s assume I find this a really important one, and I don’t even want this in any compiled app! So this shouldn’t just be a warning, this needs to be an breaking error!
This is where we will apply rulesets!
Step 1: Find out which “DiagnosticId” the warning has.
Simple: press CTRL+SHIFT+B to build your app that has those errors, and you will see the Ids in the Output window. Here is an example:
Step 2: Create a ruleset file with the changed rules.
I make this file part of my project, and I want to put it in my own .codeAnalysis folder. Like in this case, I created a “thisproject.ruleset.json” which will contain the rules that I want to bend:
And this is how the ruleset would look like. Do know there are two snippets that help you with that “trule” and “truleset”.
Step 3: Point your setting al.ruleSetPath to your new ruleset-file.
Again, this is part of my workspace settings, which look like this now:
From this moment, you’re done. Just rebuild the project (CTRL+SHIFT+B) and here you go:
Which is the expected result! Errors for the unused variables, and the warning about the parenthesis is gone! And as a consequence, my app doesn’t build anymore! How.Cool.Is.That? 🙂
Include other rulesets
You can go further, like including company-rulesets and such, but I won’t bother you with that (just yet).
It basically comes down you can include rulesets by referring to the ruleset-file within your own ruleset, by using the “includedRuleSets” tag, and point to the path. Basically a way for you to give a structure, like creating different rulesets, and decide which one to include within your workpace-ruleset. Something like that …
List of all rules
I don’t have a list of all rules, and I haven’t found a way to get to the list (yet). But as soon as I do, I will post it here.