New Best Practices in Microsoft Dynamics AX 4.0

When using the Microsoft Dynamics AX development environment, you should adhere to a set of best practices. The X++ compiler checks the code for best practice issues. These issues can result in a best practice message that is an error, warning, or informational. Best practice checks are recommended for any Microsoft Dynamics AX partner or end user who is enhancing or customizing Microsoft Dynamics AX.

Disabling Best Practices Warnings

You can disable individual warnings caused by a best practices deviation in a particular piece of X++ code. For more information, see Setting Up Best Practices Checks.


It is a best practice to have a static construct method for every X++ class. For more information, see Best Practices for Static Construct Methods.

The instance new method should be protected. For more information, see Best Practices for new and static new... Methods.

Form Design

The maximum size for a form has been increased from 800 x 500 to 824 x 668. For more information, see Forms Best Practice Checks.

The first two tab pages of data entry forms must be Overview and General.

New best practices for form design properties are:

  • HideToolbar should be set to No for data entry forms and Yes for lookup forms.

  • Columns should be set to 1 for data-entry forms.

  • TitleDatasource should be the same as the data source if there is only one data source.

  • Caption should be the same as the label defined in the TitleDatasource property for the table if there is only one data source.

For more information, see Best Practices for Form Design Properties.

Table Fields and Extended Data Types

Do not use the system recID or tableID data types directly for table fields, or for extended data types. Instead, use RefRecID or RefTableID.

If a table field uses RefRecID or a type derived from it, a relationship must be defined for that field.

Do not create a table relationship for a single field if the field is derived from RefRecId. Create a relationship on the extended data type for that field instead.

For more information, see Best Practices: Table Fields, Extended Data Types Best Practice Checks, and Best Practices for Table Relations.

Code Layout

You should now put braces round every code block—even if the block contains only a single line. Previously, it was acceptable not to put braces around single-line code blocks as long as they did not form part of an if...else statement.

Lines of code must start in tab positions (1, 5, 9, and so on). It is an error if a line of code starts in columns 2, 3, or 4.

Certain reserved words, such as if, else, switch, and while must be at the start of a code line and in a tab position.

For more information, see X++ Layout.


Use only the "//" comment notation.

Do not put comments at the end of a code line. Put them on the line before the relevant line of code.

For more information, see X++ Standards: Comments.

Naming conventions

Do not begin a name with "aaa," or "CopyOf." Do not begin a name with "DEL_" unless it is a table, extended data type, or enum, and is needed for data upgrade purposes. For more information, see Naming Conventions.


There are new Best Practices for SysPackable and SysUnitTestable. For more information, see Best Practices for Interfaces.

See Also

Best Practices for Microsoft Dynamics AX Development