Dynamics AX Development Standards and Best Practices
Standards and best practices are a great way to bring a development team together to have uniform code and features across Dynamics AX or any software project. Especially with the over-layering capabilities in AX having a set of best practices can be crucial to being successful in a project. Here are some of the Dynamics AX standards and best practices we recommend using while doing customizations and development.
Establish a source control system
Having a source control system is a very important part to managing code. Not only does it give you security while making changes, but it gives you historical data on changes made. I have used Microsoft TFS (Team Foundation Server) extensively and really like both its issue logging system and Version Control system. I’ve written a couple other blogs around Helpful TFS Queries and TFS Code Repository .
If you are going to use a source control system, make sure you get in the habit of pulling down code or “syncing”. This will keep you up-to-date and keep from conflicts occurring.
Have a task tracking system
Whether it is bugs, features, or changes life is easier if you have a way to track it. There are a lot of great tools out there for tracking this information. I have, again, mainly used TFS. It gives a large number of fields and is customizable. Emails get lost and it is hard to keep track of things that are priority. So having a central system to track tasks will help on any project.
Create a code commenting standard
When doing customizations in AX it is important to comment your code so that when it comes to for upgrades and/or hot fixes the code merge process becomes much simpler.
First, type of comment is the inline comment. Here we are adding code to an existing method. Here you want to wrap your changes with comments.
Ex.:
// BEGIN <Feature/Bug number> <Description> <Date> <Initials>
<code goes here>
// END <Feature/Bug number> <Description> <Date> <Initials>
Or:
CustParameters customParams; // <Feature/Bug number> <Description> <Date> <Initials>
This is just one standard, your organization might prefer a different comment structure.
The second type of comment is the XML header comments. It is recommended that you generate these before any public method, but it is also advisable to add it to any method that you create. Not only does it give a good synopsis of what the method does, but it can also help future developers understand when it was created and for what feature/change. The system will generate this for you by simply going to the line above the header (public int …) and typing “///” (without the quotes). This will generate something like this:
/// <summary> /// /// </summary> /// <param name=””> /// /// </param> /// <remarks> /// ///</remarks>
It is wise to fill this out and put in the <Feature/Bug number> <Description> <Date> <Initials> into the remarks section.
Use the tools available
Microsoft provided some tools to help validate best practices and standards:
Compiler BPs
The most common one is checking for Best Practice violations or “BPs” when compiling.
To do this simply go to (from the Development workspace): Tools > Options > Development.
Click the Compiler button
Set Diagnostics level to “Level 4”
Doing this will make it so that when you compile any object the BP failures show up in the message log.
Form Style Checker
Another tool is the Form Style checker. The form style checker will verify a form’s layout to see if matches that of predesigned form templates. This tool is very helpful when a new form is needed in AX. To read more on Form Style Checker, you can read about it in a blog article here.
Code reviews
Having others review your code is always a good idea. Having others review code changes gives different perspectives. This becomes even more beneficial for larger projects. When you are in the depths of coding it is easy to miss things. Having a second pair of eyes can find mistakes or code performance issues.
Doing a code review should be practical and to the point. Point out needed/suggested changes without pointing fingers or blaming. It can be hard at first to have someone review your code as you can feel like you are being judged. Instead, treat it as a chance to learn and grow as a developer.
Overlayering
In general, we (Stoneridge Software) recommend doing development in one layer. CUS and VAR are the 2 more common layers. We do not recommend doing development in the USR layer. In addition, for the most part, it is wise to only have modifications in one model as well. This makes upgrades much easier to work on.
Keep shipped code clean
While doing modifications, try to put as little code into the base objects as possible. Create new helper methods and classes to do any heavy lifting where possible. This makes it so that the base objects will only have a few lines added/modified. Of course, following the commenting guidelines mentioned above.
Use Labels
Labels are a way to do string replacement in AX. They are very helpful if your company is multi-lingual. In general, if a label exists in the SYS layer it is safe and recommended to use. I would shy away from using labels from ISVs though as they may be a bit more unstable. If unsure, it is always safer to create your own label in your own label file.
Coding standards
Every organization with a development team should have a set of coding standards.
Such as…
Variable declarations:
CustParameters custParameters: (space)
vs
CustParameters custParameters; (tab)
Comment layout
Brace placement:
if (……) (Microsoft standard)
{
……….
}
vs.
if (…….) {
………..
}
Etc.
These are just a few different things to keep in mind while doing Development in AX. There are plenty others as well. If you would like, here is the whitepaper from Microsoft on this topic: Microsoft Dynamics AX 2012 Best Practices for Developing Customizations Whitepaper.
Under the terms of this license, you are authorized to share and redistribute the content across various mediums, subject to adherence to the specified conditions: you must provide proper attribution to Stoneridge as the original creator in a manner that does not imply their endorsement of your use, the material is to be utilized solely for non-commercial purposes, and alterations, modifications, or derivative works based on the original material are strictly prohibited.
Responsibility rests with the licensee to ensure that their use of the material does not violate any other rights.