Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
> 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...
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...
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.
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.
Bluesky
