When I read Evaldas Landauskas’s blog post Development guidelines: Prefix Vs. Suffix, I thought I would write a comment below the post and share a few ideas, but then I decided that it’d be better to write my own blog post. Here I have a much better control over formatting and the content will be more visible than if it’s hidden in a mere comment.
I’m not going to dispute the argument that prefixes are better; I’ve seen teams using various approaches and I’m fine with most of them. On my current projects, we also use prefixes for most things. But I want to add a few more things to consider.
The statement that you can’t search objects by suffix because you can’t handle those ending with _Extension is underestimation of regular expressions. For example, if I want to find elements ending with either Xyz or Xyz_Extension, I can use Xyz(_Extension)?$. Is it complicated? Yes, a bit. Is it impossible? Definitely not.
Nevertheless are we doing the right thing in the first place? Isn’t our goal to find elements in our model? If so, searching by a part of name doesn’t really match our intention. We should model:”XYZ project” instead.
Finding all elements starting with a company prefix is nice, but it’s not what people usually need. A more common task is finding extensions of an existing element, such as a table. I think this should be really easy, because it’s both common and important, but we lack really good tools for that. As a workaround, some people choose starting names of extension classes with the name of the original object, which allows them to see all extensions together. We can use regular expressions again to deal with prefixes as well, such as searching for something like type:class SalesTable.*_Extension$, but any solution based on name simply isn’t good enough, in my opinion. And references aren’t great for this purpose either. But we have to live with what we have, or to build better tools.
Changing the topic, I’m also not sure where this statement came from: “We should follow Microsoft’s pattern and suffix it as well.”. As far as I know, Microsoft doesn’t address vendor prefixes/suffixes at all and general naming conventions say that “A subject area specific application object is prefixed with the name of the subject area the object belongs to, for example Cust*, Invent*, Ledger*, Proj*, Vend*”. Therefore names like RevRecAmountPercentList look correct to me.
We surely can find many places where Microsoft isn’t following best practices, just note that SalesFormLetter extending FormLetterServiceController is a special case. It used to extend FormLetter class, but it has changed when SysOperation framework was introduced. One could argue that the name should have been FormLetter_Sales instead of SalesFormLetter, but naming conventions say that it can be the case and not that it must.
I would like to thank Evaldas for giving me something to think and write about. 🙂
Thanks Martin, I really appreciate your comments and if I had to think about one person who could give me a constructive feedback, it is definitely you 🙂
My RegEx skills are basic thus making some bold statements about what you cannot was probably not the best idea. But the intention was different. The intention was to say if you were to select a prefix/suffix it’s better be unique as it will make search easier. Neither prefix nor suffix win in that first section.
Regarding finding extensions, I fully agree. We don’t have good tools to find extensions. Just yesterday I tried to find all SalesTable form extensions. In my opinion, prefix/suffix does not play the role here at all. The first search will be SalesTable anyway. Using RegEx is a way to go as you gave an example. It’s the most optimal solution though it also finds SalesTable table extensions. I used metadata search on source code, which is more accurate, but much slower.
type:class code:”[ExtensionOf(formStr(SalesTable))]”.
Naming guidelines for extensions for your reference.
https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/extensibility/naming-guidelines-extensions
They call it a prefix even it’s a suffix or an infix.
The statement came from a fictional dynamics community developer 🙂
It’s what I constantly hear/read, “it’s Microsoft’s best practice to use a suffix”.
I did not say RevRec is wrong, I just wanted to highlight that Microsoft itself does not use consistent naming. RevRec class extensions are prefixed while PayPred are suffixed.
Yes, I know SalesFormLetter is a special case and it’s all ok. I also think that the “the name of the class or, in this case a suffix should not be the identifying factor that this class is in the hierarchy”. The same applies for extensions etc.
Thanks again! 🙂
Thanks Martin, I agree with you and from my experience since I work with AX, naming objects it’s one the most confusing part, when I start, I just follow what developer leader indicate and every one have a different rule, now I’m leader and I research many blogs and docs looking for what standard and best naming practices, but I didn’t get it yet. At this part only thing clear it’s we need to avoid duplicated name objects and adding a (Pre, In or Suf) it’s still necessary in D365.
I actually use Prefix for naming customer model objects, I use the company or customer prefix, I think the reason was habit and simplicity :(, But with models view it’s not necessary anymore, So I feel some way a little bad when i use the AOT classic view and i don’t find class or tables in the same section, i don’t have any problem to find my code, find references and metadata search are the most useful utils in VS to develop.
I use Suffix for localizations models in order to follow standard objects naming, i work in countries without standard localization, So I use 3 letter Suffix with ISO code, to avoid a new standard localization can duplicate names, and i really like when all Objects are in the same section for example Sales.._BR, Sales.._IN, Sales.._XXX.
When i have to review code from other developers, one of the most complicated part it’s review events classes, Standard and ISV have their own rules to use and name classes for Events, I prefer the extension classes with CoC, but I see some developers creating many extension class for datasources when they are not necessary, just one class to handle all events in a form it’s good, extension of datasource are my last resource. this is something i found could be also standardized or have their rules, with ISV extensions + Cus extensions, follow the code without debug can be sometimes very hardcore task, in my case i don’t like to do debug always on D365 to understand all the code, wait every time for attach all the process make me mad, it’s the only thing i miss from ax2012. 🙁