1,800
Like
Share
ReportHello AX World,
In this post I am going explain why I think a prefix in most of the cases is better than a suffix.
The reason I am bringing this up is that for many years we have been developing solutions for Dynamics AX and most of the time objects and elements were prefixed instead of being suffixed. When D365 Finance came up it seems that the 'best practice' have changed and suddenly a suffix became a thing and I cannot find a good reason why. And I don't like to blindly follow the best practice.
I am not trying to say that you should all start using a prefix now. Do what you like, as long as it's consistent in your projects. I will just explain why I think a prefix could be more beneficial.
Let's get started!
In general, both a prefix and a suffix should be unique enough so they could be easily found in AOT. And by found, I mean searched and not just browsed like good old times we used to do. Search or metadata search is quite powerful and makes our lives much easier. You can find results much faster.
However, prefix has an advantage here. You could tweak your search by searching for the objects that begin with a prefix by using regular expressions. The only thing that will not be found is metadata extensions as they are obligatory suffixed.
You cannot do that for a suffix unless it's a postfix, but then you won't find objects like class extensions as they obligatory end with _Extension.
Well, you could probably do XYZ* search. But it will also find elements having no Z (e.g. containing only XY) as * make it zero to many Z in this case.
So, it's better be unique.
Searching by the model would make the same trick. Prefix/suffix search is just faster, you need to type less.
Searching by the model would make the same trick. Prefix/suffix search is just faster, you need to type less.
Alphabetical order makes it easier
Prefix makes it easier to find a group of objects of the solution.If you browse data source fields, you will see all of them next to each other.
Prefixed database elements like tables and views are easier to find in SQL as they all are next to each other. Well, you can filter, but by default you will see them all sorted alphabetically.
Prefixed objects will be next to each other when you select it in the property sheet.
And finally, prefixed objects will always be filtered in the intellisense when you start typing a prefix.
Extensions
But Evaldas, extensions use suffix. We should follow Microsoft's pattern and suffix it as well.
No, that's not entirely correct. Microsoft themselves does not follow a clear guideline.
If you look at one of the latest new models introduced, Revenue Recognition you will see that it clearly prefixes application elements with RevRec.
Even class extensions are prefixed.
But if you look at PaymentPredictor model, it's mixed.
Most of the objects prefixed, while class extensions are suffixed.
However, I do agree that finding extensions next to the extended object might be helpful. Though, I never needed that. I was always looking for something specific where I knew a better way to find. Also, find references help a lot and are more reliable as it's the result of compilation and not just naming.
But if you look at PaymentPredictor model, it's mixed.
Most of the objects prefixed, while class extensions are suffixed.
However, I do agree that finding extensions next to the extended object might be helpful. Though, I never needed that. I was always looking for something specific where I knew a better way to find. Also, find references help a lot and are more reliable as it's the result of compilation and not just naming.
So, if you work on multiple different projects where you don't set the guidelines you better be equipped with diverse tools and techniques to find what you are looking for.
Well-known class naming
You do probably know that there are classes that by default we postfix with something.
Attribute classes we postfix with Attribute as it was the requirement before (not anymore).
Data provide classes we postfix with DP.
Data contract classes we postfix with Contract.
Controller classes we postfix with Controller.
Etc.
Suffixing them would not make them look nice, so I prefer to prefix them.
Classes in the class hierarchy
I am not gonna lie, suffix for a class of a hierarchy looks nicer and you can find this class close to the classes in the hierarchy.
However, if you look further, classes do not necessarily follow this pattern.
SalesFormLetter extends FormLetterServiceController which already falls out of the naming coherence of using a suffix-like naming.
In my opinion, the name of the class or, in this case a suffix should not be the identifying factor that this class is in the hierarchy.
You can always check the entire hierarchy by right clicking on the class and selecting View Hierarchy.
Interfaces
Another place where I like a suffix more than a prefix is naming interfaces. The naming standard for the interface is to prefix with I e.g. IDisposable. It probably looks nicer to have IDisposableXYZ than XYZIDisposable. IXYZDisposable does not look nice either.
Method names and variables
In general method names and global variables in an extension classes should be prefixed to avoid naming conflicts. The prefix should be of lower letters as this is the naming best practice for method names and variables.The prefix gives you advantage in intellisense when you need to find methods and variables defined in the extension.
However, there is an exception to this rule when it comes to well-known methods like parm, get, set, find, exists etc.
I think method names for those methods should be suffixed. The suffix should come after the parm, set, get or similar first verb word.
To the list of well-known methods I would also add methods like validateField, modifiedField etc. If you are making your solution version of these methods on a standard object it's better to suffix them like validateFieldXYZ, modifiedFieldXYZ etc.
Summarizing
I believe that I have not covered it all, but you can see my point.
In my opinion, a prefix works better in most of the cases, though suffix could also be used in some, so I guess a combination of both could be a solution.
Here are my recommended guidelines for using a prefix/suffix:
- Select a unique prefix/suffix.
- Use a prefix for all new objects that are not an extension or a part of inheritance. Don't use prefix/suffix for sub elements of a new object, unless it's necessary.
- Use a prefix for sub elements in metadata extensions if not doing so could cause a potential naming conflict.
- Prefix or suffix a class extension (choose one). I prefer prefix.
- Prefix or suffix a class in inheritance (choose one).
- Suffix interfaces.
- Prefix methods and variables in elements extending a standard object, a prefix should be of lower letters.
- Suffix after the first verb well known method names like parm, set, get, find, exists etc. as well as your solution version of well recognizable methods on standard objects like modifiedField, validateField etc.
- Don't follow the guidelines blindly. Use common sense, if something does not fall into a category or makes no sense, discuss it in a team and decide your own guidelines for that.
- Be consistent.
Let me know what you think in the comments if you have a different opinion.
Be aware and take care!
Be aware and take care!
*This post is locked for comments