Naming Conventions: Methods

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

Write a clear, descriptive name for your method. If one cannot be found, consider splitting it up.

Use the general name standards, and the following preferred names for methods.




A Boolean method that checks a condition. If the condition is not fulfilled, it must put a warning on the Infolog, and return false.


Returns a Boolean that is true if a record with the supplied key exists, see static exist Method Design Pattern.

Typical use: Table static method.


Returns a record indicated by the supplied key.

Typical use: Table static method.


Finds a record in the table (where the method is declared). The postfix is the name of the field which is used for accessing the table, or a logical name for more fields.

Typical use: Table static method.


This buffer is initialized with values from the buffer supplied.

One argument, which is a buffer of the same type as that named in the method.

Typical use: Table instance method.


Used for methods that set member variables. If the method only sets some of the variables, indicate this in a prefix to the name, for example initParmVersDate.


A Boolean method that will check some condition. If the condition is not fulfilled, it must return false. is* cannot change the method. Information must not be sent to the Infolog.


Methods used for setting and getting the value of a member variable as a part of an object initialization. The method should have the same name as the variable, prefixed with parm.


Used for methods that set value(s) in the object. The name must make it clear that the method also sets the state of some other global members. set* methods should be void or Boolean, signaling the result of the set.



If a method updates or creates a record, reflect that in the name, rather than calling the method setĀ FieldName.


Same as check*.


Methods that have the names listed in the preceding table must carry out the tasks described, and must not have any additional functionality. For example, there must be no assignments in a validate, check*, or is* method.

See also

Best Practices for Methods

Best Practices for Parameters

Best Practices for Table Methods

Best Practices for Local Functions

Best Practices for Method Modifiers

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