Package in object name, why should you do it?
I know this may not be universally agreed upon, but I think it’s something worthy of being discussed and so I decided to explain my reasoning behind it.
Although I started my programming career in ABAP over the years I’ve programmed in Java, C#, Objective-C,etc. In these languages an object has a name, and a fully qualified name:
- Name: Delivery
- Fully Qualified Name: com.sd.litigations.delivery
The benefit of this structure is that the “litigations” team doesn’t have ownership on the usage of the “delivery” word, like a trademark. There can be another object called delivery in another package like “com.sd.whatever”.
In ABAP you have something similar, the custom namespaces, which you may have seen in SAP developments /<application>/ but are rarely used outside SAP (I’ve used this once in a project). Most of the times we all share the Z or Y namespace.
So In my arrogance I create a package called ZLITIGATIONS, go into SE24, and claim the name ZCL_DELIVERY for myself (like I’ve seen people do so many times….). Why should I be encouraged to do this? Is my litigations application more important that some other package? No.
That’s why in my projects we use some sort of package symbol in the class name, like ZLT_DELIVERY. This way someone else can create a DELIVERY object without it feeling like a “second best”, besides making it easier to search for the class with intelisense (in ABAP for Eclipse).
PS: I know some will question why there would be two delivery classes in the first place, but let’s keep that for another discussion. Think of another less widely used object, the same reasoning applies.
Yes that makes good sense!!
I totally agree with you
This needs to be kept in mind ensure more clear coding as well
Hello Joao,
Is this FQ name generated by the system? Seems so to me.
I think you meant ZCL_LT_DELIVERY, didn't you? 😉
In most of the projects i have worked on the naming conventions are generally the way you have proposed. For e.g., ZCL_XX_<meaningful name>, where XX = application area viz., FI, MM, SD etc.
But due to the limitations in the length of the names of workbench objects sometimes i shun these XX things. For me it is very crucial that the class is named properly, e,g., ZCL_DELIVERY_REP_MODEL, ZCL_DELIVERY_REP_CTRLR, ZCL_DELIVERY_REP_VIEW. What do you think?
BR,
Suhas
The com.sd.litigations is the name of the package. The FQ is defined by the package name + object name. The diference between ABAP and other languages, is that the classes are global, you don't have to use "import" directives to say which packages you are using.
In other languages you only use the fully qualified name, if the name is not enough given the packages you chose to import.
Actually no, I feel using it is redudant. The fact that it is a class is explicit by the way it is used:
One of the reasons I don't use CL in the name.
The reasoning sounds good to me. But then how do you know if the code is working with an interface & a class, just by looking at it.
I never thought about dropping the prefixes because the standard SAP guideline for naming workbench/repository objects suggests -
In one of the projects, we had a naming convention where the class name did not have CL_ in it. But when i tried to create an exception class without the CX_ prefix, the system would not let me create one. Then we thought may there are some internal checks on the names & after reading SAP's guideline on naming the objects we decided to use the CL_, IF_ etc.
Generally the names of classes, interfaces, reports are quite manageable (30 character, i think). The problem comes when naming DDIC tables, they always give me headaches. 🙁
Actually I use IF and CX, but not CL. The fact that I drop CL is because it's the most widely used type. Maybe I do it because that's the way it's done for example in Objective-C, where only the interfaces have specific naming convention.
But you are right, SAP nomenclature is a bit demanding if you take into account the limited space available.
Thanks for clarifying.
I really like the content you post because they make me "think" am i doing it the right way. And i hope you don't mind me pestering you with lots of questions 🙂
For me the "thinking" part is the most important, sometimes people do stuff in a certain a way because that's the way they were taught and never question it.
I have the benefit of having worked in so many framework, with so many "conflicting" rules, it makes you think since they can't all be "right".
I could not agree more - "I think, therefore I am"
Well, SAP itself does not follow the guidelines 100%, so why should I?
If I had my way, I would get rid of all this prefixes. Unfortunately I have to adhere to company's guidelines, which usually are based on SAP's guidelines 🙁
Good blog and discussion !
True, SAP nomenclature can be followed to the max possible, barring some less descriptive objects.
Hi Joao,
Interesting thoughts... I too have made great use of the fully qualified naming of Java objects - mixing up java.util.Date and java.sql.Date in the same class for instance where a bridge from frontend to SQL layers is needed.
Having said that however, in 15+ years of working with ABAP, I've never come across an instance where a clash of objects has been an issue. I'm not sure if this is by design or just good fortune... 😉
I also don't like using "CL" in the naming of objects. I get particularly annoyed when data dictionary objects have their type in the name, such as Z_CUSTOM_PO_TB or Z_CUSTOM_PO_ST for instance. I've always believed you should leave this sort of stuff out and concentrate on giving the object a meaningful name for its function, ie what it does, not what it is.
Cheers,
G.
I admit doing so, but mostly in cases of defining table types -
But i hate the TTY(table type) thing though 🙂
BR,
Suhas
PS - I try not to piss off the QA dudes too much by not following the naming conventions 😛
I think it's by design, but its a design that:
Have you ever tried to export a custom Package (with all it's objects and declared package dependencies) to a fresh Netweaver? Did you ever get a green light after import? Never happened to me, because someone always uses an object from a "foreign" package with no declared package dependency......
I think that's one of reasons I see so much rework in SAP projects.