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 Weber )

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 das )

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 )