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: 

Why dont we like hard coded literald

Former Member
0 Kudos

Hello Abapler,

I am planning a workshop for developers concerning guidelines. They shall use less hard coding.

But... Why ?

It is clear for me in cases of translation. But what other reasons are there.

Do you have any source, ideas, examples ?

We are working with classic Abap and little OO

Thanks for every help !

Simone

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Takes less space for one if the same text is used in more then one place.

Also, if you have to change it and it's used in more then one place, you only need change it in one.

7 REPLIES 7

Former Member
0 Kudos

Takes less space for one if the same text is used in more then one place.

Also, if you have to change it and it's used in more then one place, you only need change it in one.

0 Kudos

>

> Also, if you have to change it and it's used in more then one place, you only need change it in one.

And if you used hard coding you will have to change it not only in several places but in all places. And most likely you will forget to change one place. The results can be strange...

One thing I would like to add: Most likely your developers will produce bugs once in a while. Or if they are perfect someone will try to use their programs for something they were not developed for. In the end you (or them) will have to debug the source code. And it's helping a lot if you can just search for a constant by it's name. If you just see in the code of somebody else that a 'magic' parameter is set to 42 you will have a really bad time to find all other places where 42 is used with the same intention.

But this are all reasons that are not restricted to ABAP. It's true in every programming language. And there is one easy way to teach a programmer not to use hard coding whenever he can avoid it without major performance drawbacks: Just let him do maintainance for some weeks...

Best regards,

Jan Stallkamp

0 Kudos

Hello Jan,

good idea to let them do the maintanance.

Many developers are very optimistic :

returncode , Exceptions, try - catch and constants are for pessimists - aren't they ?

Ciao

Simone

0 Kudos

Hello Simone.

Ok, I'm a little bit biased. I'm working in an area of SAP where I have to dig into older source code quite often. And the most I learned about writing good (or better: robust) source code was when I started to deal with existing source code. One of my first software projects (back in the days at university) was to rewrite the entire GUI of a bigger program. And I learned more from that than from any class about software engineering...

Best regards,

Jan

Former Member
0 Kudos

Simone,

hardcoding is a BIG no-no. it reduces flexibility.

If, for ANY reason you need to change that value, you must update the progam. Then, the whole program needs to be moved to Test, Unit tested, run through a QA team, given to functional team and end user for more testing, approved, and finally moved to production.

whereas if you stored that in a table, you could more easily update just that table value.

this is a very simple concept - not sure if you are an ABAPer, but you might want to have them provide the guidelines and workshop.

uwe_schieferstein
Active Contributor
0 Kudos

Hello Simone

One of the 10 (or more) commandments of decent programming is:

"Thou shallst not use any hard-coded literals."

The other ones can be found in Andy Hunt's The Pragmatic Programmer book.

Example:

You have many custom financial reports using a hard-coded VAT value of lets say 21.0 % (UK).

As we all know the VAT is every now and then increased. Using hard-coded VAT values you need to find all of them (no traceability, Where-Used-List ) and change each of them.

In contrast, if have a class ZCL_TAX with a constants MC_VAT = '21.0' you need to change the VAT at a single place and using the Where-Used-List for this constant you see immediately which reports will be affected by this change.

Regards

Uwe

SergioFerrari
Active Contributor
0 Kudos

This message was moderated.