Suffix or prefix

(0) Share

Report

Posted on by Community Member

Hi,

in most of my previous projects we used as prefix when developing customizations (like XYZSalesTableAdditional) but in my current project they do SalesTableAdditional_XYZ. What do you use/think about?

*This post is locked for comments

I have the same question (0)

All responses (6)

Answers (1)

Suggested answer

Denis Macchinetti 16,444 on at

Like (0)

Report

Hi

I use prefix for all the new objects, like XXX_objectname

Then, I use suffix for all the new attributes, like methods, fields, index, etc.

Obviously, for the new objects ( tables, classes, etc. ) the attributes will haven't any suffix\prefix

About the attributes, I prefer to use the suffix so I have the fields, etc. in alphabetic order, also with intellisense.

Was this reply helpful? Yes No
Suggested answer

PA-22040759-0 6,194 on at

Like (0)

Report

In AX 2012 where your code belongs to a model, I wouldn't add pre- or suffix if the name of the model clearly identifies the solution.

The counter argument I usually hear when suggesting this, is that it opens for a risk of name conflicts with furture standard code. My usual answer is that you most likely have bigger problems if standard AX ships with elements having the same names as your elements; either you have duplicate functionality or you have been really bad at naming your elements to reflect what they do.

But it is not something that could keep me up at night. So another answer could be; whatever your team is comfortable with.

Was this reply helpful? Yes No
Verified answer

Florian Hopfner 2,461 on at

Like (0)

Report

If there was a fast and easy way to clearly identify your customizations, I would be with Palle Agermark and say: Forget this prefix and suffix crutch.

Unfortunately, there is not and the available standard tools to identify customizations are unreliable (e.g. ghost datasources). So I guess we have to live with the crutch. For me, that means prefix all the way, even for parm and find methods. I do not want to have to remember exceptions :)

Was this reply helpful? Yes No
Martin Dráb 237,965 Most Valuable Professional on at

Like (0)

Report

I don't fully agree that you can avoid name conflicts (as we don't have namespaces). You can if you develop a new model and your business area prefix (according to standard naming conventions) makes the name unique, but if you extend a standard module, you can easily create similar functionality as somebody else and if you both use the best name, you have a name conflict.

I don't like these prefixes (or suffixes) - they often makes the code less readable and people sometimes tend to distinguish names just by a company prefix instead of a logical name (e.g. TransDate/XyzTransDate). But I think they're necessary evil, because we don't have any better solution.

Was this reply helpful? Yes No
PA-22040759-0 6,194 on at

Like (0)

Report

Name spaces are high on my wish list :-)

Was this reply helpful? Yes No
Maxim Gorbunov 456 on at

Like (2)

Report
Apologies for posting in an old thread. This debate is at least 10 years old. There was indeed an old version of X++ best practices that recommended using company prefixes. This recommendation was revised long time ago but somehow it still resurfaces every now and then.

Personally I thought that we, X++ development community, have outgrown this holdover. However, having had a chance to work with a few new applications over the past few months, I found that company prefixes are still used and used quite extensively by completely unrelated teams of developers. What was even more startling, I discovered that prefixes have found its way into several books on X++ which claim that the use of a company prefix is a best practice (see Microsoft Dynamics AX Implementation Guide by Yogesh Kasat, JJ Yadav). Company prefix is not a best practice!

As Palle noted above, the main argument of prefix proponents is that it helps to avoid name conflicts. But a name conflict of this sort is actually an early sign of functionality duplication and I would prefer to see such an indication rather than discovering it later in a functional testing.

In my opinion, prefixes do not help developers and administrators in any way but they create quite a few extra problems:

Objects belonging to the same module/function are harder to find as they are no longer placed next to each other in the AOT.

Object names become harder to read especially if prefixes are starting to build up. For example, company ABC created a table which was named ABC_NewTable. Then, company XYZ took over the application and created a method returning cursor in table ABC_NewTable. If company XYZ used prefixes too, the new method would be named XYZ_ABC_NewTable() (you may find it hard to believe but this really happened, this is not just a hypothetical example).

AIF has certain requirements to naming of methods in the document and table classes: their names must start with predefined prefixes (parm, exists, create). Therefore, company prefixes cannot be used when modifying those classes anyway (unless we modify AIF itself).

Was this reply helpful? Yes No