Naming Conventions in Microsoft Dynamics AX

Hi there!

I remember when I started developing software ... oh man, time goes fast as it was many years ago. In my first job I had a manager that would always reminded me to create clear naming conventions for my objects. He believed this was the base for any software development design as they were really important when scaling up an existing application. Yes, he was right!

Later in my life I started working in bigger teams, and one of the things that caught my attention in these environments was the fact that there were many developers that didn't care about creating consistent naming conventions when writing code.

Yes, this is horrible and makes it hard for the person who is later maintaining or scaling up the system.

There is a great quote about this:

“ Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. ” - Rick Osborne 


Luckily we don't have to work under the pressure that a psychopath will come to our homes at night if we don't write good naming conventions...But, what about the customer and/or employer who trusts us in doing a professional job?

To be honest with you, I think that dealing with a psychopath is much easier than dealing with an unhappy customer ... They support our lifestyle!

When I started working with Microsoft Dynamics AX, I rapidly understood the importance of getting into the habit of writing well defined naming conventions as the application objects are not only data types and classes (in the case of early languages), but tables, enums, macros, forms, data sets, queries, menu items, services, etc.

In addition, naming conventions contribute to consistency and to making the application easier to understand. I think that the basic rule to create good naming conventions is to do it from three basic components:

{business area name} + {business area description} + {action performed (for classes) or type of contents (for tables)}

Examples:

• CustJournalPrintOutInvoice

• PriceDiscAdmDelete

• PriceDiscAdmSearch

• PriceDiscAdmName

• PriceDiscAdmTrans

Also, take into consideration the following:

• All names must be in U.S. English.

• The default rule is to use logical and descriptive names if no other specialized rules apply.

• Identifier names have a limit of 40 characters.

• Names must be spelled correctly.

• Names must be used consistently.

• All texts that appear in the user interface must be defined by using a label.

• Do not begin a name with nonsensical or confusing prefixes, such as "aaa" or "CopyOf".

• Do not begin a name with "DEL_" unless it is a table, extended data type or enum, and it is needed for data upgrade purposes - doing this may cause unexpected results.

As you can see, by following these simple rules, we can start making a big difference in our code. Let's get into the habit ... otherwise the psychopath will get you!

Take care!