Best Practices Checks

Artikel
05/18/2015

Applies To: Microsoft Dynamics AX 2012 R3, Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012

Check your own code and application objects for compliance with the best practices for Microsoft Dynamics AX.

Select Tools > Options.
Click the Development area, in the toolbar, click the Best practices button.
In the Warning level list, select the checks that you want to perform.

This will mean that best practices are checked when you compile or check in an object.

You can also check best practices for one or more nodes in the Application Object Tree (AOT): right-click the node, and then select Add-Ins > Check Best practices.

In this guide, conformances that can be checked this way are marked with these symbols: Error icon , Warning icon , Information icon . Approximately 25 percent of the Best Practices that are described in this guide can be checked by the tool.

Results

Results are displayed in an Infolog, with the following severity code:

Information: Things that might be nice to know (shown in blue).
Warnings: Things that you should strongly consider fixing (shown in yellow).
Errors: Things that should definitely be fixed (shown in red).

If you double-click on an error message, this will open the code editor.

Fix the Problems

It should be a goal to remove as many of the warnings and errors as possible, with the focus on increasing the quality of the solution (not just to reduce the number of errors in the Infolog).

Note

You cannot check code that causes a Best Practice error into the version control system.

The Best Practices checks cannot give anything more than a good guess or an idea. Although you must fix Best Practice errors, in some other cases your own solutions will be better. As a guideline, this might occur for 5 percent of Best Practice warnings.

Disable Individual Warnings and Errors

You can stop a particular piece of code from causing a best practice warning or error in two ways:

By using a BP Deviation documented comment
By using the SysBPCheckIgnore macro

Warning

You should not disable an error or warning message unless the code needs to violate the best practice rule for a known reason.

Use a "BP Deviation documented" Comment

You can disable certain warnings caused by a best practice deviation in a particular piece of X++ code. The warning is "disabled" by decreasing the severity to an Information message.

To prevent a piece of code from causing a warning, add a comment above the line of code causing the problem, with the text:

//BP Deviation documented

Use the SysBPCheckIgnore Macro

You can stop a piece of code from causing a particular best practice error or warning by adding the following line of code to the SysBPCheckIgnore macro:

c+=[[# BPErrorCode ,@" AOTLocation "]];

You do this in situations where:

BPErrorCode is the error code for the warning/error as listed in the SysBPCheck macro.
AOTLocation is the location of the object causing the error, in the Application Object Tree (AOT).

For example, to disable an error message caused by renaming a class to ProjTransCostForecast, you would write:

c+=[[#BPErrorObjectNameConflict,@"\\Classes\\ProjTransCostForecast"]];

After you have edited the SysBPCheckIgnore macro, you need to recompile the SysBPCheck class, and then exit Microsoft Dynamics AX. When you restart Microsoft Dynamics AX, the error or the warning will be suppressed.

Share via