Sometimes unavoidable, mostly unnecessary and nearly always present: hard-coding in developments. Sign your name in solid concrete.

Sometimes it's literary printed in a functional specification: select form somewhere for company code "XX34". The report is designed for this company only and there is no expectation of use for other companies. But is that enough reason to actually block all other company codes from using the program ?

Because coding a selection to pick up "XX34" is much easier than a flexible approach - hardcoding is often introduced right at the beginning when developing. An overhaul (which is performed later on) is a good moment to revisit hard coded solutions - and make them more flexible. First of all:What is hardcoding ?

What is hard coding?

Hard coding is all about checking values against constant values - which are defined in coding in the program. Some examples:

SELECT * FROM T001W WHERE WERKS EQ '2201'. 

or

CONSTANTS c_my_plant LIKE T001W-WERKS VALUE '2201'. 

SELECT * FROM T001W WHERE WERKS EQ c_my_plant. 

or

CASE movement_type.
  WHEN '631'. 
    perform go_left.
  WHEN '633'. 
    perform go_right.
  WHEN '636'. 
    perform go_down_below.
ENDCASE. 

The values mentioned in the above coding examples are "hard-coded" into the program. To change them, a developer needs to change the program.

Why it is a problem?

A program should be designed to perform a task - without limiting it to functional settings. Even though it is (initially) designed for a restricted set of actions, this restriction should not be "coded" in the ABAP language. It's a form of "bad coding practice" that wil lead to unflexible coding. An example: movement type 630 needs to be set up to perform go_left just like 631. And 631 should be performing routinego_right. These changes will need to be done in ABAP coding which will need to be transported through the landscape. An ABAP developer needs to be involved to add a little more hard-coding (and the saga continues...)

Possible solutions

So how can hard-coding be avoided ? There's 3 ways/directions that can be used:

• Controlled hard-coding use constants to define hardcoded values.
  This is a way to make sure the hard-coding is not hidden away in the program, but the values that are checked are defined in the program header as constants. When a change needs to be done, a developer still needs to get involved. The advantage is that the CONSTANTS statement will list the hardcoded values which is good for overall clarity. Another advantage is that the constants that are defined have a where-used list, and thus it's quite easy to check where the hard-coding is used. The value '631' can be used in several locations and adding a '630' movement type would need to be done in several locations as well. Error prone... The controlled hard-coding is a last resort method, and should be avoided if possible. However if e.g. the field that is hard-coded is a status or list of statusses that represent a document being closed - it can be an effective way to keep the program understandable.
• Diverted hard-coding use a function module that is centrally re-used.
  Your system uses a material type which is a bit special: materials of this type should be processed in a different way by a variety of programs. The material type is set to a single value which is not likely to change in the near future. For this example a function module that determines whether the material type (or material) is "special" can be set up. This module will do a hard-coded check and return the answer to the caller. The main advantage of diverted hard-coding is that when another material type is added later on, there's only one spot to change - the function module itself. Another nice advantage is the where-used list of the function module: it will reveal where this bit of diverted hard-coding has been implemented. This is a form of hard-coding that is ready for the future.
• Flexible hard coding also called Flexible hard coding The values that hardcoded are picked up from the database. A blue-print setup for this is described in another article on AbapcadabrA (see end of article). In effect the requested values (and control variables to indicate which sub-process or routine should be used) are stored in a transparent table which is picked up when the program starts. Make sure the availability of the settings is checked (for starting up). Changing the settings can change the behaviour of the program without actually changing the program itself. This is not made up here - this is exactly what SAP customizing is all about ! (it's by excellent example... )

• Prev
• Next