In Microsoft Dynamics AX 2009, the X++ compiler is sometimes too flexible in its rules for code. It is likely at some of these flexibilities will be eliminated in future releases.
This blog entry describes some flexibilities of the X++ compiler that we recommend you not utilize.
 Sequence of Default Parameters
Recommendation: In a method declaration, declare parameters that have default values after the last parameter that has no default.
The X++ compiler and runtime currently allows you to disregard this recommendation, as the following code example demonstrates.
static public int AddTwoNumbers
(int _firstNum = 4
return (_firstNum + _secondNum);
The following job calls the above AddTwoNumbers method. Notice there is no way to accept the default value of the _firstNum parameter.
static void Job1(Args _args)
iAnswer = MyClass::AddTwoNumbers(8 ,16);
print( IAnswer );
 Access Modifier on Methods
Recommendation: Each time you create a new method on a class, explicitly add an access modifier to the method declaration, meaning public, protected, or private.
If no access modifier is given, the default behavior is public.
 No Access Modifier on Classes
Recommendation: Do not add an access modifier to any class declaration.
The X++ compiler ignores the keywords public and protected and private on classes, so adding an access modifier can only confuse other programmers. In effect, all X++ classes are public.
 Put TODO First
Recommendation: The TODO should be the first non-whitespace after the start of the comment.
When the X++ compiler detects the string TODO in a comment, it lists a task on the Tasks tab of the compiler output window. The compiler goes a little too far in trying to detect a TODO. For instance, the TODO is detected in each of these two examples:
// Remember TODO Remove the diagnostic prints.
/* Important TODO:
Rewrite this SQL as a more efficient set operation.
The two above examples would be fine if the first words were removed: it would be better to remove the first words Remember and Important.