文章目录
1 Introduction
ABAP offers various options for avoiding such code duplicates and for giving a piece of program code a name under which it can be called:
Form routines (these are officially obsolete)
Function modules (this is what this is article is about) and
global classes and their methods. In most cases these are the better choice. A class can have multiple methods. This is a better structure than to have a large number of function modules that have little connection with each other.
2 Detail
Use ABAP Development Tools for Eclipse (ADT)
Is there an alternative to ADT? Nobody would use Notepad to write Java… Seriously: refactoring capabilities (rename method!) as well as ABAP Doc comments are essential features for us. Thus SE80 is not an option.
Put Everything in Classes and Methods
Do not place functional code in programs (reports) or function groups/modules. As we come from Java, this is quite obvious. We use reports and function modules only if there is no other solution possible, e.g. for providing an RFC interface. And also in the rare cases where we had to leave the OO-world, these classical ABAP only serve as a proxy delegating to the actual implementation in a class.
Structure the Source Code by OO Concepts only
Especially, do not use includes. In our own codebase, there was only one exception: When we migrated our code from Z to /CQSE/ namespace, we wanted to keep the old Z programs as legacy interface for a while. Thus the Z programs just included the new /CQSE/ programs, we preferd this approach over code duplication.
Rules for Naming and Usage of Identifiers
In ABAP, it is common to use type prefixes in identifier names (Hunga