Skip to Content

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.

To report this post you need to login first.

13 Comments

You must be Logged on to comment or reply to a post.

  1. Suhas Saha

    Hello Joao,

    • Name: Delivery
    • Fully Qualified Name: com.sd.litigations.delivery

    Is this FQ name generated by the system? Seems so to me.

    That’s why in my projects we use some sort of package symbol in the class name, like ZLT_DELIVERY

    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

    (0) 
    1. Joao Sousa Post author

      Is this FQ name generated by the system? Seems so to me.

      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.

      I think you meant ZCL_LT_DELIVERY, didn’t you? 😉

      Actually no, I feel using it is redudant. The fact that it is a class is explicit by the way it is used:

      • DATA: You use REF TO;
      • Methods: You use -> and =>
      • References: You use “lo” instead of “lv”.
      • Transaction: You use SE24 instead of SE38

      But due to the limitations in the length of the names of workbench objects sometimes i shun these XX things.

      One of the reasons I don’t use CL in the name.

      (0) 
      1. Suhas Saha

        Actually no, I feel using it redudant.

        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 –

        1. Use the package name
        2. Distinguish the type e.g., CL_, IF_, CX_ et al.

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

        (0) 
        1. Joao Sousa Post author

          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.

          (0) 
          1. Suhas Saha

            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 🙂

            (0) 
            1. Joao Sousa Post author

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

              (0) 
              1. Suhas Saha

                Joao Sousa wrote:

                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 could not agree more – “I think, therefore I am”

                (0) 
        2. Custodio de Oliveira

          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 🙁

          (0) 
  2. Gareth Ryan

    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.

    (0) 
    1. Suhas Saha

      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 admit doing so, but mostly in cases of defining table types –

      • TAB – Standard tables
      • TAS – Sorted tables
      • TAH – Hashed tables

      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 😛

      (0) 
    2. Joao Sousa Post author

      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 think it’s by design, but its a design that:

      • Forces you to create objects with less meaninful names or
      • Makes people use objects from other packages that have nothing to do with the current application, creating unnecessary dependencies, and upgrade nightmares.

      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.

      (0) 

Leave a Reply