Excerpted with permission from Wolfgang G. Propfe's book titled "ABAP with Style." To purchase the text, click here.
Hardcoding is considered a shortcut, but it comes with a price tag. If a programmer hardcodes the language
It is excusable to write out literals in a program as long as nobody expects those texts to be in the logon language of the user later on, or else the text symbols are a good standard mechanism. But even then you may want to consider some style and memory concerns as you write the program. If a literal is longer and is used more often, you should use constants instead, because they only need to be maintained in one place and they use up less memory. Imagine a string of 120 characters for a company heading 'ABC Company, a subsidiary of DEF Enterprises blah blah blah' to be written in different places in the list. For each reference, pure hardcoding would store 120 bytes inside the program for the literal, unless an optimizing routine is smart enough to detect the redundancy (we can not be sure about possible built-in optimizations and we can not rely on them.)
By using a constant, not only do you not have to search through the program in case of a name change, but also each usage would only reference the constant for a total of a few bytes each. (The space occupied by a pointer to a constant could vary depending on the operating system. But generally speaking, a reference to a constant uses less storage than a repetition of the whole string and in preferred for maintenance reasons.)
If the language or logon parameters are implied, side effects such as a numeric conversion short dump can occur.
If you use WRITE x TO y instead of MOVE x TO y, the user defaults are used for formatting. If a numeric value is written to another field of type C, all is fine for values up to 999. Then SAP inserts a separator, which depending on your settings could be '.' or ','. This turns 1000 to '1.000' (possibly interpreted as "1") or '1,000' (likely to cause a short dump when trying to use the field as a numeric later on.)
Using constants is a good idea for the obvious reason, e.g. when a label or other literal will be used more often in the program. But don't use constants for their own sake alone. Some don't make sense at all. SAP uses a few called CHARA, CHARX and so forth, where CHARX is a TYPE C constant of length 1 with the value 'X'. What does that do to improve hardcoding? Nothing. It is too short to effectively save space, and there is no maintenance benefit either, because the value of CHARX cannot change- or else its name would be very misleading (just picture what havoc a programmer could wreak by changing CHARX to an 'A'.)
Just like with domains and data elements you should think from the object's perspective. There are different kinds of 'X's in a program. An 'X' may be used as a checkmark for checkboxes and radio buttons, it may be a Boolean flag for yes or no, or it may be the character 'X' out of a value set of letters (E.g., in pricing the inactive flag has an 'X' for incorrect price, a 'Y' for subsequent price in the calculation, an 'A' for price exclusions, etc.)
A checkmark value cannot change, but instead of calling it CHARX, it would be better to call it C_CHECKED or so. The Boolean flag could be called C_BOOL_TRUE and the value could be called C_INVALID. If tomorrow you want to switch your logic to have Booleans as 'Y/N' for 'yes' or 'no', you simply change the value of C_BOOL_TRUE without affecting C_CHECKED and C_INVALID.
Sometimes the hardcoding is implicit and harder to find. Some customers prefer to set up the valuation area in T001K as 1:1 with the plants in T001W. Coding a SELECT against T001K where BWKEY is equal to T001W-WERKS is a form of hardcoding too. One day, the 1:1 relationship may no longer be desired, and such programming would cause lots of incorrect or missing entries in the retrieval. On the other hand, looking up the BWKEY from T001W by plant and using it for T001K (the proper way) does not hurt, even if the relationship is 1:1. Just weigh the benefits of that shortcut against the possible damage in the long run.
This was first published in July 2002