Site icon DAXRunBase

Deep Best practice checks with layer filtering in compiler

DAXRunBase

You can (and should) enable best practice checks for the MorphX and X++ developer environment, which is similar to the dotNET FxCop code analysis tool. Though the standard Microsoft Dynamics AX 2009 code does not have any best practice errors, you can still find a lot of warning and info type problems.

Update: Microsoft just released a new version of the BP document, which is available here: Microsoft Dynamics AX 2009 Development Best Practices White Paper

To enable best practice checks, go to the menu under Tools/Options, then press the Compiler button on the right. You have to set Diagnostic Level 4 to enable the compiler to check your code for necessary and possible optimizations.

Then under the Best Practices you can select how deep inspection you want to run on your code, where the “All” warning level with each checkbox ticked provides the most thorough validation.

If you reopen your client and compile the SalesTable form, you will get several hundreds of BP violations – most of them can be ignored, but you still have some space for optimizations.

Now the interesting part is if you have your own customizations on SalesTable on a lower layer, you only want to see best practice errors relevant for the objects that you have changed and do not want to show all the standard bugs. To do that, we slightly have to modify the compiler. Start by adding the following components to a project:

Add a string field to the temporary table named UtilLevel with a stringsize of 3 characters. Then add CompileErrorCode and UtilLevel fields from the BestPractices formdatasource to the BestPracticesGrid.
Now go to the SysCompilerOutput class and add the following code near the end of the compilerOutputMessage method:

            tmpCompilerOutput.LatestCompile             = true;
            tmpCompilerOutput.CompileErrorString        = _errorString;
            // --> New section
            tmpCompilerOutput.UtilLevel                 = strfmt('%1', TreeNode::findNode(_path).applObjectLayer());
            // <-- New section
        }
        tmpCompilerOutput.LatestCompile             = true;
        tmpCompilerOutput.write();
    }
    if (addCnt)
    {
        this.incrementCount(sysCompilerOutputTab, sysCompilerSeverity, addTotalCnt);
    }
}

If you compile your objects with BP enabled, you have the option to filter for only those objects that you have changed by the application layer, or get the specific compiler error code to clean it up by types.

Exit mobile version