Explained – Hard Code vs Constants vs Parameter entry

Premise:

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’

WA1-OPTION = ‘EQ’

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.

IF SALES_ORG EQ ‘ABCD’.

*Get the address data of Sales org.

ELSE.

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

ENDIF.

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.

Disadvantages:

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

Disadvantages:

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

Disadvantages:

• 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:

Step1: 

Create table in SE11 – ZCONS

• The first column in this table is CLIENT of type MANDT
• Second column is type of development.

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

Step2: 

Create table in SE11 – ZCONS_ITEM_P

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

Step3: 

Create table in SE11 – ZCONS_ITEM_S

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

Step4:

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,

Tapo.