D365FO Development Naming Conventions

Naming conventions for any development environment normally are decided by the business.  However, there are some rules that should be considered when establishing a naming convention.  Certain patterns provide clarity, some readability, and others confusion.  The goal of a naming convention is not just standardization and consistency, though those are large reasons to create a naming convention.  Another goal should be providing concise information about a solution, project, or object that provides enough traceability for a user to find more details if needed.  While Microsoft might not have released a best practice around these naming conventions, there certainly are best practices that will benefit the D365FO community at large. These recommendations are, in my opinion, common sense but through experience I have found that they are not as universal as one would expect.

---

Selecting a Prefix

Every customer or partner should use a prefix for their objects.  The prefix should reflect the name of the business but should only be 2 or 3 letters.  For example, a company called Ice Cream might use “IC” as a prefix. Or the same company might use “ICE” as the prefix.   This prefix allows all the custom objects to group together, making it much easier to find custom objects when just browsing visually, without applying any filter.  A prefix also allows easy recognition when writing code as to what is custom and what is standard.  Where ICESalesTable is easily established as custom because of the prefix.

On the topic of prefixes, it should be noted that using an underscore after a prefix is NOT recommended. While one might argue it adds readability, it reduces readability within code, which is the primary place all the custom objects are used.  Sure, it might be nice looking at the AOT (application object tree) and seeing ABC_xyz, in code it makes it less user-friendly and less intuitive. For example, most variables are not going to include an underscore in the name unless the are a parameter passed into the method.  Adding an underscore to the object but not the variable would make the naming different than normal X++ code.  For example, ICESalesTable would likely have a variable named iceSalesTable.  However, ICE_SalesTable would also likely be named iceSalesTable to avoid using an underscore in the variable.  Is this an insurmountable problem? No, of course not, but simple things do help prevent mistakes.

For more information on the important of prefixes and things to consider, review Microsoft’s brief documentation: Naming guidelines for extensions - Finance & Operations | Dynamics 365 | Microsoft Learn

---

Visual Studio Solutions and Projects

Naming conventions for Visual Studio solutions and projects is slightly different because the main purpose of that name is for readability and providing information about what it is for.  The name of the project is not normally directly used in code which is why there can be a slight deviation here.

The start of the project name should still be the selected prefix for the company. The next part of the name should be the Azure DevOps task/bug/work item that is associated with the work about to be done. There is no need to add an underscore between the prefix and the DevOps ID, because ultimately it looks ridiculous. A project name does not have to read like a sentence, it just needs to provide information about the purpose in a succinct manner.

My recommendation is after the DevOps ID, then an underscore followed by a Pascal Case brief description.  A brief description should be describing why the project exists.  Something that just states an object name or report name is not incredibly helpful. For example, ICE1234_CreateNewReportFunkyOrders provides more information than simply, ICE1234_ReportFunkyOrders. Why? The former provides enough information to know this is a new report that is being created.  The latter could simply be a change to a report and does not provide any real useful information to make a good assumption without having to refer to DevOps. It should not be necessary to go to DevOps just to know why a project exists. 

Parts of the project name:

• Prefix - Tells which company did the customization.

• DevOps information - Provides an ID to lookup in DevOps for more information.

• Underscore – Separation for readability.

• Description – Pascal Case description that is short but provides key information to understand why the project exists.

---

AOT Objects and Extensions

For any new object, the name should be the selected prefix followed directly by the object’s name.  As discussed previously, the goal should not be to try to make AOT objects readable; the goal should be to make the objects easily usable in code. 

Even for objects where the last letter of the prefix will be the same as the first letter of the object’s name, the naming convention should remain consistent.

ABCContactTable

ABCContactForm

ABCContactMenu

As for the suffix of the name, whether or not the description of the new object is necessary is debatable. In my opinion it adds clarity but is overkill.  Microsoft is not consistent in how it handles object names, making them a poor example to lean on.  Overall, the addition of the suffix that describes what the object is (like all suggestions here) will be up to you.  My biggest suggestion here would be that whatever you decide, make it consistent.

For extensions, Microsoft provides recommendations: Naming guidelines for extensions - Finance & Operations | Dynamics 365 | Microsoft Learn. The use of the prefix selected will fit nicely in with what Microsoft has provided for recommendations.

That’s all for naming conventions. Agree or disagree with the recommendations, at least be consistent in your approach.