Best Practices for Parameters

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

Parameters best practices are as follows:

• Format as camel case. For example, forUpdate and recID.

• Names begin with an underscore. For example, _parameterName.

• Do not use the business area prefix in the name unless it changes the meaning. For example, HcmBenefit _benefit.

• If omitting the business area prefix is the name changes the meaning then do provide the business area. For example, CustTable _custTable.

• Put each parameter/argument on a separate line. For an example of an X++ layout with more than one parameter, see X++ Layout

• Align the types and the parameter names horizontally. For example:

DialogField addField(

    int         _type,

    FieldLabel  _label = '',

    FieldHelp   _help = '')

Example 2:

Class MyClass()
{ 
    MyType myVar;
    public MyType parmMyVar(MyType value = myVar)
    {
        myVar = value;
        return myVar;
    }
}

Do not have unused parameters, unless you are overriding a method or implementing an interface. You will get a best practices warning for unused parameters in private methods, and a best practices info for unused parameters in public and protected methods. This is because the parameters might be used elsewhere in the class hierarchy.

See also

X++ Layout

Announcements: New book: "Inside Microsoft Dynamics AX 2012 R3" now available. Get your copy at the MS Press Store.