Unfortunately It is not very rare to see sloppy codes in ABAP especially if you are working as a consultant. In this blog you can see my selection of worst ten examples. Some might be debatable but some are definitely not. It would also be nice to discuss examples, cases you experienced in comments section.
1. Complete program with no modularization blocks
Hundreds sometimes, thousands lines of code with no modularization blocks, no includes. Conditions with hundreds lines of codes. No readability, definitely, It is my worst nightmare to be asked to correct or change this kind of code. It is not really different having only 2-3 modularization blocks with hundreds line of code.
2. Modification/repairs
Not all of them, but if any modification is done without enough investigation might cause big issues in time and I guess everyone would be agree it is not a good approach to modify standard programs without searching any alternative solution. So I would suggest to think again if you are often doing modifications. And check first if it is possible to make enhancement instead of modifications.
3- Not considering performance
Codes with nested loops, one big loop with 30 select single, inside, select *, uncontrolled “read”s. They will decrease the performance more than you can imagine and should be avoided all the time. You can avoid some of them using proper design and many alternative options are in place only if you search them.
4- Development in productive and quality assurance systems
Not very often, but it is not impossible to see such cases, no need to say it may cause big headaches and you are taking big risk if for any reason you are doing this.
5- No success and failure checks
I have seen few of these kind of program, probably it is thought that every single statement in the code will run smoothly but it is not always the case. and If you can not see any sy-subrc checks in a program this is not a good sign at all.
6- Not using exceptions
Very similar to point five, it is nice to consider all possibilities and implementing exceptions as described.
7- Copying big templates to every program
Especially for ALV, it is easy to prepare a template with all functionality and copying this template any time where ALV is used.Even it helps to save time, if any function is not needed for the copied programs they should be cleaned, if they are not they will cause issues.
8- Too many global definitions
Global definitions should only be used if they are needed by design, and in a good design they should not be needed too much.
9- Lack of comments
Readability is very important, and where a complex logic is coded it is very helpful to put some comments to explain what is exactly done.
10- Too many errors and warnings after SLIN and SCI checks in a recently developed program.
Things might change in time quickly in programming and easiest way to see if we are on a good track in terms of development quality is using automated tools like SLIN and SCI. It is very easy to use, very explanatory and will save us from lots of mistakes. If you are not using this tools you might never know, if something that you have coded is right or wrong. Using these check tools will easily cure most of the mistakes mentioned above.
It seems ten is not enough I am also adding other points should also have been in this list which are mentioned in comments section
11- Copying standard programs ( From matthew.billingham)
If you copy standard programs, in every upgrade there will be difference between copy program and new version of the copied standard which is not a good thing. And it will require big efforts to adapt new functionality into copy program.
12- Writing code like 1999 ( From patrick.weber4 )
Using obsolete statements all the time it is very annoying.
13- Badly formatted source code. ( From peter.inotai )
It effects readability negatively.
14- Avoid 'Hard codings' (From tuhin.das20 )
while displaying any text in the program. We should try and use standard text and text elements as much as possible.
15- Using exit and commit work statements in enhancements (From johnson.ittyerah ).
The EXIT ensures that any new functionality that you add below doesnt even run because the EXIT is encountered. And the COMMIT WORK leads you on a wild goose chase when you encounter an Update error sometime later.
To keep all the troubles away ABAP programming guidelines ( from horst.keller )
I am happy to announce there will be a session based on this blog at TechEd Barcelona, You can check its details here.
