Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Question about use constants instead of using hard coded strings

Former Member
0 Kudos

sorry for my poor english.

recently, we've been forced by project development leader to use constants

instead of using hard coded strings.

for instance,

IF GR_ALV->IS_READY_FOR_INPUT( ) EQ 'X'. <------WRONG(X)

IF GR_ALV->IS_READY_FOR_INPUT( ) EQ C_X. <------CORRECT(O)

I know exactly what CONSTANTS meaning

but why should we use constants like C_X????

thanks.

Edited by: Tae-Hwan Shin on Oct 18, 2011 8:58 AM

1 ACCEPTED SOLUTION

SuhaSaha
Advisor
Advisor
0 Kudos

Hello Tae,

In your specific case, i'll go with your Dev Leader since the value returned by the method is not controlled inside the program. If sometime down the line the method returns '1' instead of 'X', if you use the CONSTANT you can change it in the declaration part without bothering about where it is used.

But you should use meaningful names while defining your CONSTANTS for e.g., instead of C_X use C_TRUE.

Also bear in mind all organisation data(e.g., Plant, Company Code, Controlling Area etc.) should be defined as CONSTANTS & not hard-coded. In these cases i prefer using the variant tables(TVARVC) to maintain the constants.

I don't want to start a flame-war here, but imho although use of CONSTANTS increases the maintainability but too much usage of them reduces the readability. With all due respect to those "over diligent" QA reviewers AUTHORITY-OBJECT 'S_TCODE', ASSIGN COMPONENT 'MATNR' et al. are not hard-codes, please don't ask us to declare them as constants

BR,

Suhas

PS: I remember there was an SDN blog on the same topic & it was definitely an interesting read.

6 REPLIES 6

Former Member
0 Kudos

You have to use constants instead of hard coding, suppose if you want to change vise versa simply change the constansts content values, it will reflicate automatically throught the program.

Other thing it is coding standard you should not hard code the values.

Edited by: sFayaz on Oct 18, 2011 9:01 AM

yogendra_bhaskar
Contributor
0 Kudos

I think you should use TYPE-POOLS : ABAP. because it contain global values of constant , may be your Tm or PM wants to use some global variables .

and in your method offline due to compatibility issue you have to write c_x or you can use abap_true if you use type-pool ABAP in your code.

Former Member
0 Kudos

Hi,

another good reason is that you can make programmes more readable: a lot of constants are just a letter or number, while constants can have meaning. For instance in HR:

'P' can be constant co_person, 'O' can be constant co_organisation.

I agree that C_X instead of 'X' doesn't add much value. For 'X' and ' ' I use ABAP_TRUE and ABAP_FALSE, by the way. These are standard available in most programmes. If not, add type-pool ABAP.

Roy

Former Member
0 Kudos

Hi ,

Hardcoding is considered a shortcut, but it comes with a price tag. If a programmer hardcodes the language 'E' or 'D' (Internal code for English or German, probably the two most frequently used languages in SAP in the world), he ultimately deprives the system of language independence when the company decides to do a global rollout. Going back to all programs later will be more expensive than considering the language in the design from the beginning.

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.

SuhaSaha
Advisor
Advisor
0 Kudos

Hello Tae,

In your specific case, i'll go with your Dev Leader since the value returned by the method is not controlled inside the program. If sometime down the line the method returns '1' instead of 'X', if you use the CONSTANT you can change it in the declaration part without bothering about where it is used.

But you should use meaningful names while defining your CONSTANTS for e.g., instead of C_X use C_TRUE.

Also bear in mind all organisation data(e.g., Plant, Company Code, Controlling Area etc.) should be defined as CONSTANTS & not hard-coded. In these cases i prefer using the variant tables(TVARVC) to maintain the constants.

I don't want to start a flame-war here, but imho although use of CONSTANTS increases the maintainability but too much usage of them reduces the readability. With all due respect to those "over diligent" QA reviewers AUTHORITY-OBJECT 'S_TCODE', ASSIGN COMPONENT 'MATNR' et al. are not hard-codes, please don't ask us to declare them as constants

BR,

Suhas

PS: I remember there was an SDN blog on the same topic & it was definitely an interesting read.

0 Kudos

Though the change from 'X' to using CONSTANT C_X doesn't seem to make much of a difference in this case, the reason for doing so (in general) can be summed up as:

1. Improving the readability of the program. In generally accepted coding standards, hard-code values are not encouraged. Instead, declaring a constant and giving a meaningful name ( ae mentioned above, like c_true) to it makes the readability of the program much better.

2. In case there is change in the value that is being passed or compared (in this case 'X'), we would have to replace every such occurance in the program. Rather, it would be helpful if the constant ( example c_true) was declared just one and reused in the program. In case of any change in the value of the constant, a change in the declaration part would be suffcient.

Edited by: Aneel Rodrigues on Oct 18, 2011 9:35 AM