Skip to Content
Personal Insights
Author's profile photo Tapodipta Khan

Explained – Hard Code vs Constants vs Parameter entry


I have been asked below questions by several programmers constantly.

  • Is It ok to Hard code?
  • Should I use a Constants in my program?
  • Or Do I need to maintain a parameter for a scalable solution?

Let’s take a deep dive onto this topic. At the end of this blog you will be able to decide when to use a constant when to hard code and choose from different options for maintaining global parameters.

Also, I will explain what the pros and cons of the different approaches are.


 Why should programmers think about Constants?

Twenty years ago, when I first learnt about programming constants were explained to me as a value that never changes during the program execution. – e.g. the sky is always blue so that is a constant in a computer program.

Reality is in today’s world there are always changing requirements for every piece of code written, conceptually scalable solution is always better many organizations that I have worked with in the past requested a more flexible and scalable solution.


its Bad coding if we Hardcode.

Hard coding not necessarily means bad coding, it depends on the intention or business logic. As an example, let’s look at below Example 1 this is not a problem.

On the other hand, if I code for a business data as in Example 2 that is not considered as a good coding practise.


Example 1: Sign and Option are used in ABAP for creating a select option programmatically any version of the SAP. These values of ‘I’ and ‘EQ’ do not change from program to program or with changing requirements. If this is hardcoded in the program it doesn’t necessarily impact the program scalability.

I can potentially replace this with a constant GC_SIGN and GC_OPTION in the program if we are using the values multiple time in a program.


WA1-SIGN = ‘I’



Example 2: Sales org is a system configuration and potentially there can be more sales orgs added which requires the data to be picked up from Sales org address instead of business partner of sales order below example is considered hard coding even if I declare a constant with ‘ABCD’ in its value.



*Get the address data of Sales org.


*Get the address data of a business partner from Sales order.



Best Practise: Any programming logic based on conditions of business data, configuration or master data should not be used as constant in a program. This will reduce scalability and solution will potentially loose flexibility to adapt to future requirements.



Alternative Approach: Use of parameters in Program.

I have seen several different approaches in the past to try and parameterize data in ABAP codes to make a solution more scalable.

When designing a more scalable solution using parameter table entries few points to be noted.

  1. Try to avoid creation of multiple database tables for same purpose.
  2. Create a common framework to access the parameters and guideline.
  3. Common re-useable code to access these parameter entries from different applications.
  4. A where used functionality to find usage.


Here are few options: 


Option 1:  Use of TVARV* tables to maintain constants for ABAP programs.

The solution works many Standard SAP program even use this concept to parameterize certain entries.

Benefit of this option:

  • I don’t need to create any additional tables in DB.
  • I can maintain both single parameter and multiple parameters.
  • A common re-usable code can be created to use this for any program.


  • Security and access control to these variant tables are difficult in my experience end users were able to make changes to these tables which broke the solution.
  • By looking at the table entry difficult to under in which program these entries are used unless there is a strong naming convention followed. It is difficult to pinpoint which program is using the entries.
  • Table must be data logged always as these are client modifiable any user with right access can change entries.


Option 2: Usage of Sets in GS01/02/03 transaction.

Mainly while working with SAP finance Sets are a good place to store certain constants you can parameterize both single and multiple records.

Benefit of this option:

  • No need to create additional table.
  • To read a set already standard SAP functions available – G_SET_GET_ID_FROM_NAME and G_SET_GET_ALL_VALUES.
  • Maintenance of the data is easy.


  • Data logging is enabled to ensure changes are captured.
  • Access control of the set values.
  • Where used functionality of the set values.


Option 3: Creating Y/Z-Tables to hold constant values.

Create your own customer specific tables to manage parameters.

Benefit of this option:

  • Full control of customer specific code parameters.
  • Potentially creation of where used functionality.
  • Easy governance and Access control.


  • Create your own database table.
  • Re-useable component needed along with standardisation in the org so every developer can use the re-useable component.
  • Maintenance.


Summary: All above options are good for a scalable solution it depends on how far in the future I can see while coding. Future proofing code is not easy because of changing requirements so it is preferable by many to go for Option 3 due to the flexibility in the design.



Below is a simple example of such a Framework:


Create table in SE11 – ZCONS

  • The first column in this table is CLIENT of type MANDT
  • Second column is type of development.
R= Report
I = Interface
C = Conversions
E = Enhancements
F = Forms
W = Workflow
O = Others
  • A free text field such as parameter name.
  • This column is the program name where these parameters are be used.
  • Finally, a description of the parameter.



Create table in SE11 – ZCONS_ITEM_P

This table should hold only parameter value for the parameter name maintained in ZCONS.



Create table in SE11 – ZCONS_ITEM_S

This table should hold only Select option value for the parameter name maintained in ZCONS.



Create class or function to read entries from these tables using program value and parameter name.

This allows you have a where used functionality of the parameter constant value.



Conclusion: Scalable solution is good, but it will always be limited to visibility of the developers.

  • Do not overkill/create complex code for constants, parameter maintenance.
  • It is wrong to expect all solution can be future proofed with parameter entries.
  • There are always requirements to change the code and add, update or remove code blocks.
  • Future proofing code is always a good idea when business data, configuration or master data specific business logic are used.
  • If a data value doesn’t change for any of SAP application ECC, S/4 it’s safe to hard code that in a program without worry.
  • Use constants to avoid repetitive hard coding of the same value.
  • Avoid – Multiple parameter or constant entry table.
  • Try to limit number of constants in a program.



Hopefully this was helpful, and you are now able to decide the differences between Hardcoding, Constants and Parameter tables.


Best Regards,




Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Patrick Coenen
      Patrick Coenen

      Nice analyses, you could contemplate to enrich this analyses with BRFplus implementations

      Author's profile photo Tapodipta Khan
      Tapodipta Khan
      Blog Post Author

      Definitely I will add a new one with Screenshot and working examples.

      Author's profile photo Shai Sinai
      Shai Sinai

      One point I would like to add:

      The main advantages of Constants are readability and traceability.

      Author's profile photo Matthew Billingham
      Matthew Billingham

      Another advantage - especially when the value is reused within the program - is it helps prevent typos.


      Author's profile photo Jelena Perfiljeva
      Jelena Perfiljeva

      Yes, and constant names should be meaningful. GC_OPTION in this example should be rather gc_equals because that's what the value represents.

      Author's profile photo Jelena Perfiljeva
      Jelena Perfiljeva

      The post started well with explanation of hard-coding and constants but sorry to say, it went a bit downhill afterwards. It says:

      All above options are good for a scalable solution it depends on how far in the future I can see while coding.

      The 3 options are actually not very good solutions and we are already living in future relatively to the options described, so we can see it. All this stuff predates BRF+ by decades and BRF+ has been around for many years already.

      TVARV table (transaction STVARV, btw) I'd say is mostly used with background jobs or in the old programs when we had no other choices. Personally, I'm not a fan of using this other than it was intended and BRF+ could be used instead these days.

      Option 2 I honestly never heard of but this is also something old and hardly deserves mentioning in the scope of "best practice" blog. (For historic purpose, here is a blog that describes this functionality in detail.) Again, why not just use BRF+?

      Custom tables - OK but not in the way described. That's just "custom TVARV", so why reinvent bicycle? "Create class or function" - on EHP7 or later, create a CDS view to consume and maintain the table. In older systems, create a class. There should be no more functions created (other than the few unavoidable scenarios such as RFC).

      Overall, this would've been fantastic blog about 10 years ago. It's nice of you to share but please, please going forward share more modern ABAP practices. If we still need to write about the "old stuff", it should be only in the context of working with legacy code. When writing about current best practices, we need to be more careful what guidance we offer to the new generation of ABAPers.

      Thank you.

      P.S. Clean ABAP includes some guidance on constants as well.

      Author's profile photo Shai Sinai
      Shai Sinai

      BRFplus is a great choice for business logic, but I'm not sure it's a nail which should replace every constant/modifiable parameter, so a generic solution like option 3 (but maybe more advanced one) is inevitable.

      Long ago I worked on a solution which offers maintenance of constants/parameters via maintenance view and automatically generate classes out of it.

      This allows to enjoy of both worlds: Easy maintenance and easy usage on code (including an implicit where-used functionality).

      Author's profile photo Jelena Perfiljeva
      Jelena Perfiljeva

      I agree completely that BRF+ is not a panacea and Z tables with collections of random values still have place. But I feel that particular example for option 3 is too much parameter/selection-option oriented. It should be more generic IMHO.

      Real life example. Someone implemented a generic "constant" table to store some random values. But they "hard-wired" the table key to select options with SIGN, OPTION, LOW, etc. fields. That artificially limits the usefulness of the table. I've seen more generic design work much better in other systems.

      Author's profile photo Tapodipta Khan
      Tapodipta Khan
      Blog Post Author

      Thank you for sharing your thoughts. There is no silver bullet to solve all problems in one go so even old technologies mixed with newer tools can be very useful. BRF+ definitely should be there.

      I do see a few problems with TVARV specially in terms of getting a where used functionality of global constants. For large organization and big code bases it is a problem to find out where a constant is used.

      Appreciate your insight.