Skip to Content

What are constants?

Every programmer learns about constants in one of his first classes. Constants are used to refer to a single reserved block in the memory and can never be changed during runtime (at least in ABAP). It is defined once and can be referenced as many times as required. The main idea behind it is that if the value must be changed you only have to do this in a single place. Imagine a general TOP include which is used in many programs. Declaring your constants in here saves you a lot of effort when you need to change the value. This is nothing new.

Constantitis

People with constantitis have an uncontrollable urge to remove literals from their source code at all costs. They create constants blindly. Often this is accompanied by a total halt of logical thinking.

How do you recognize the symptoms? If you take a look at ABAPs you’ve written and you find constants named for example co_x (containing the value ‘X’) or co_1 (containing the value 1) then I’m sorry – my friend – you might have constantitis 🙁

Luckily for you, it’s not too late! Read on!

How constants should be used

An example: I create an ABAP for sales org NL01. Because the sales org value is used in the program I have to define a constant (because I’m a good programmer and I shiver at the sight of literals in ABAPs).

If I define the constant like this:

CONSTANTS: co_nl01 TYPE vkorg VALUE ‘NL01’.

What happens when – in the future – I have to use my ABAP for salesorg DE01 instead of NL01? Because I have defined the constant in the top of my ABAP I know I only have to change the value once. What you get is this:

CONSTANTS: co_nl01 TYPE vkorg VALUE ‘DE01’.

Although technically this works I hope we can all agree that this does not make sense. It’s like saying 1 = 2. To make it more logical/readable you should also change the name of the constant and with that you screw up the entire concept of using constants.

So what I’m saying is: avoiding literals in your program by using constants is the right thing to do, but do not include the value in its name, like co_x with value ‘X’ or co_1 with value ‘1’. Choose a logical name (more like a description) such as:

CONSTANTS: co_salesorg TYPE vkorg VALUE ‘NL01’.

or

CONSTANTS: abap_true TYPE abap_bool VALUE ‘X’

This may sound logical and it should be. But I come across this a LOT, even in standard SAP code.

To report this post you need to login first.

28 Comments

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

  1. Ian Stubbings
    Hi Roel

    Indeed, a major frustration of mine in reviewing others code.  My favorite is c_space type c value ‘ ‘.  Ever heard of the global constant SPACE!!!??

    It appears that this plague is a result of ensuring the code satisifies extended code checks etc. I have seen whole chunks of sentences placed in constants or variables before – just to ensure there no literals.  Really bad practice…

    Cheers
    Ian

    (0) 
    1. Roel van den Berge Post author
      Haha, yeah c_space is also a classic one.

      It could also be a habit from other programming languages. Often it is also registered in guidelines, made by people who are not even programmers themselves (as mentioned to me by Tobias Trapp a while ago).

      Cheers, Roel

      (0) 
  2. Guido Brune
    Hello,

    altogether the naming of variabels and constants is very import.

    I would name a variable to its semantic meaning.

    In this concrete example I would say:

    c_salesorg_NL01 type …

    In coding naming of variables is one corner stone
    to maintainable coding.

    All the best,

    Guido

    (0) 
    1. Roel van den Berge Post author
      Hi Guido,

      Thanks for your reply. I do agree that variables/constants need to have a meaningful name.

      But including the value of the constant is exactly what I think is wrong. Suppose you only need the ABAP for this sales org and by some strange requirement the name of the salesorg is changed to NL02.

      Then when you need to change your ABAP you would get c_salesorg_NL01 TYPE vkorg VALUE ‘NL02’. To keep it logical you would then also need to change the name of the constant which destroys the advantage of having constants.

      I think it would be better to name it co_salesorg_netherlands, co_current_salesorg or co_default_salesorg. The name should describe what it’s used for, not what its value is.

      Cheers, Roel

      (0) 
  3. David Greengas
    I always like to use the type somewhere in the constant, so I definitely agree with C_SALESORG. For something like sales org C_SALESORG_NL01 makes sense since even in business terms sales order NL01 is used rather than a more region or unit specific one like Netherlands Region 1.
    However, in some cases I agree having the value in the name makes no sense. This could be something like a system status in production order where SAP internally stores it as something not meaningful like I007. In that case it would make sense to the declare the constant like C_STATUS_RELEASED.
    In any case, I really cannot stand reading code with constants like Constants C_X Type C Value ‘X’. I have seen it!
    Great post by the way. All developers should be forced to understand this before they allowed a developer key.
    (0) 
    1. Roel van den Berge Post author
      Thanks for your input and I agree with you. Salesorg as a constant was for that matter not the best example to demonstrate what I was trying to point out since it is very unlikely to change. The status constant would have been a better example.

      Cheers, Roel

      (0) 
  4. Sudhanshu Bhagat
    I agree to your point and appreciate your efforts blogging it here.

    There can be a lot many ways to avoid such situations.

    I would Use parameter statement  in selection screen for the example above and even if i have to give a value i would do it on screen , create a variant “default”  for by selection screen and call transaction with default variant. Here i get the help of functions like “protect Field ” , “Hide field ” , “Required Field”.

    Hope we discuss others here as well.

    (0) 
    1. Roel van den Berge Post author
      Hi Sudhanshu,

      I agree that there are better ways to make a report more flexible than by using a constant for the salesorg. Your suggestion is a valid one for that.

      It was not the point I was trying to make though. My point was that including the value of the constant in its name can destroy the advantage that constants bring. Namely having one single place to update a value that is used multiple times (in multiple programs even).

      (0) 
  5. Manas Dua
    Your blog highlights the issue really well and it is written in a fun way..but what do we do in cases when we have to use 2 constants like:
    c_salesorg_nl01 – for NL01
    c_salesorg_us01 – for US01

    In this scenario one would be forced to use suffix nl01 and us01.

    (0) 
    1. Roel van den Berge Post author
      Hi Manas,

      Thanks for your kind words!
      Let me ask you a counter-question: why would you use constant c_salesorg_nl01 instead of just the literal ‘NL01’? What is the advantage of a constant here?

      (0) 
      1. Manas Dua
        Advantage of constant would be Where Used List of this constant. Once declared in top include or as class attribute you can do a where used list and check where all this constant in used

        If you use a literal then you would have to run code scanner to find out the usage of this literal through out the code

        (0) 
        1. Roel van den Berge Post author
          If that is a requirement and if a descriptive meaning is less meaningful then the value of it (because the value is well known in the company) then I guess indeed that naming it c_salesorg_nl01 is the way to go. Thanks for pointing that out. I didn’t think of the where-used list.
          (0) 
        1. Roel van den Berge Post author
          Yeah I agree. There is a point where you’d have to ask ‘how likely is it that this literal is going to change?’. If it is unlikely to change I can see the benefit of just using ‘KUNNR’ instead of a constant (because the field customer number will never change in KNA1). You shouldn’t create a constant just for the sake of removing literals.

          On the other hand I can imagine the advantages of putting authority objects and transaction codes in constants. Instead of literal ‘ME21N’ it is better readable to use c_transaction_create_po (at least for the last poor souls that do not know that ME21N is used to create POs). And should transaction ME21N ever be renamed to ME21 you only have to change it in one location.

          (0) 
  6. Ian Stubbings
    Some very interesting points being made and I totally agree with Suhas’ sentiments.  Here is another example.  Here we have 2 constants that will be difficult to understand without the comment and impossible where the constant is actually used in the code.

      CONSTANTS : c_persk1 TYPE persk VALUE ’03’.  “Managers
      CONSTANTS : c_persk2 TYPE persk VALUE ’04’.  “Senior Managers
     
    Why have 1 and 2?  Why not remove the comment and have:

    CONSTANTS : c_managers_subgroup TYPE persk VALUE ’03’.
      CONSTANTS : c_senior_managers_subgroup TYPE persk VALUE ’04’.

    Perfectly understandable in all areas of code and if the value changes, it does not affect the name of the constant.

    (0) 
    1. Alejandro Bindi
      Agree in general with the comments on this debate, it’s very annoying yet it happens very frequently when you read loads of code.
      What I found to be a good approach and began to use frequently in this case of multiple constants values of the same type, is this:

      Instead of declaring:

      CONSTANTS : c_managers_subgroup TYPE persk VALUE ’03’.
      CONSTANTS : c_senior_managers_subgroup TYPE persk VALUE ’04’.

      I would use:

      CONSTANTS:
      BEGIN OF c_subgroup,
         managers          TYPE persk VALUE ’03’,
         senior_managers   TYPE persk VALUE ’04’,
      END OF c_subgroup.

      This has some advantages:

      – All constants related keep the same prefix, e.g. c_subgroup-managers / c_subgroup-senior_managers without having to repeat it on each value declaration.
      – There’s less possibility that some careless developer adds another constant of the same type in another distant place, using whatever prefix/suffix he/she sees fit, as this structured constant is more visible.
      – This allows for dynamic processing of the values, for example to fill some range, using DO + ASSIGN COMPONENT. If later you add a value inside the constant, it’s added to the range as well without any modification.

      I hope you like this approach.

      As for “constantinizing” technical info such as field names, authorization objects and such, I’m on the opposite front. Generally if such info can change it’s far preferable to make it configurable in some DB table (or at least load it once in an internal table and then process the itab generically).

      Regards

      (0) 
      1. Sudhanshu Bhagat
        Dear Alejandro Bindi,

        This is a more practical approach . Totally agree.

        I use this for return codes after Performs and functions . It gives me a clear idea of what and where . The returning values are more or less unique .

        Regards

        (0) 
  7. Matthew Berry
    Constantitis is usually when coding standards are run amok. Any standard should be an 80/20 balance. Try to use the rule 80% of the time.

    Think about:
    The global constant interface is an anti-pattern

    Replacing all literals in regular expressions or XSLT makes your coding look like nonesense.  I would rather read a regular expression or Xpath function inline then have to look up what each constant is just so I conform to a no-literal rule or my where used works? 

    (0) 
  8. Anonymous
    I have always tried to avoid using constants because it restricts the flexibility of the program. To your point about the salesorg, if you had made it a parameter instead of a constant then you wouldn’t have to alter the code at all and the client would have a more robust tool to use.

    Also, if SAP has already defined the variable then what is the purpose of redefining it? I becomes a question that all programmers should have in the back of their mind; Will this variable ever need to change? If the answer is yes then the creation of a constant makes sense, if not then I typically make it available in the selection screen logic.

    Your thoughts?

    Daniel

    (0) 
    1. Anonymous
      Will this variable ever need to change? If the answer is no then the creation of a constant makes sense, if not then I typically make it available in the selection screen logic.
      (0) 
      1. David Flad
        This is an interesting dailog to be sure.  I think one of the fundamental aspects that is being overlooked here is another reason you create constants. 

        So far, it was mentioned to eliminate literals in code, and to make code maintenance easier.  The overlooked reason is where the value of the constant is required in MANY places in the code.

        You create a constant to hold the value so that when you maintain, it’s in a single location to maintain, and then all code occurences will work.

        BTW, I also agree with the comments around whether to put the literal as part of the name or not.  Here again, it depends on the purpose for the constant.

        If defined as a generic reference that could need to change in the future, then using a business-content naming approach (i.e. manager-group, customer_id) makes sense.

        However, as others have pointed out, you need to consider how this data element will be consumed.  If this is part of a report or screen with user interaction, then expose it directly as a parameter or a selection variable instead of a constant.

        Lastly, for a constant that gets widespread use and will rarely change, referencing the literal value as part of the name IMPROVES code readability.  SAP itself has numerous examples where they themsleves have taken this approach.

        Coding some global constants like:
        c_chg  type c value ‘C’,
        c_disp type c value ‘D’

        These are much more readable in code where you either want to set something to change or display, or determine the mode.

        if mode = c_chg.
          do something special.
        elseif mode = c_disp.
          do not do anything dangerous.
        endif.

        (0) 
  9. Rainer Hübenthal

    I agree with you but in your example the fault is not to use a constant but the name for the constant is just chosen wrong.

    So i can makes sense to have

    c_sales_org_exception type….

    (0) 

Leave a Reply