Thoughts on element prefix vs. suffix

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. 🙂

One Comment

  1. 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! 🙂

Leave a Reply

Your email address will not be published.