Best practice checks.

Mar 11, 2013 by Dick Wenning Category: AX2012, AX2012 R2, Uncategorized 0 comments

When checking my Ax code, I always use best practice checks. Most of the time I perform this during the last 10 minutes of the day. I do not use compiler level 4 but I have to admit this has some issues.

Most of these issues make sense, but some of them are contradictory or cannot be solved because the core AX framework is programmed the wrong way.

My preference is to start with these settings.



From this point it is up to you what checks can be skipped. Skipping means not to comply with

But, in case you do not wish to follow this direction, I could give some tips so the imported checks stay on

–        Labels

  • Turn off help labels, in most projects I review they are not used altogether.
  • Use of Labels: if you use single quotes instead of double quotes the warnings disappear.
  • Use the description {locked} on labels from the developer documentation on tables.

–        AXBc Fields on tables: You can ignore this unless you are using the fields in AIF.

–        XML documentation: I know this is a lot of work but did you know that the remark section is optional? See

–        “Customizing this class may cause problems with future upgrades to the software.” warning

/// <remarks>
/// This is a   framework class. Customizing this class may cause problems with future   upgrades to the software.
/// </remarks>


Ok, so far so good, now it is time for the freak show:

–        Reports

  • New should be protected. If you do this your report will not run anymore…..

–        The Construct method must only instantiate the class. Consider using a static new pattern instead.

  • I have just extended a class from the sys layer which does not follow this best practice, therefore it is a design issue for MS….

–        Forms

  • Listpage interaction classes: Implement static construct to allow for modifications. It will never be used…
  • My parameter form uses data that is partition independent, so the table is of type Framework: You will get all kinds of warnings of wrong captions in the parameter form.
  • An Action Pane should not be present on a form that is not a list page or other content page. This is an outdated warning, only relevant to AX 2009!
  • A document handler button on an Action Pane should use the label @SYS114630 for its Text property. The code seemed to be targeting the name property and the text property separately  but the check however seems to be asking for two different text property values, which is obviously impossible.

At the end I am still not happy with it: there are other checks such as broken relations, editable primary indexes, obsolete code and missing labels (this can happen when you use TFS, check in the EDT first and next check in the label, the label on the EDT is not corrected).


Leave a Comment!

Your email address will not be published. Required fields are marked *