ABAP Keyword Documentation →  ABAP Programming Guidelines →  Structure and Style →  Naming → 

Names of Repository Objects

Background

Repository objects are development objects that you edit using the tools of the ABAP Workbench. Each repository object is assigned to a package. Packages encapsulate the repository objects contained and use package interfaces to make objects available that should be usable outside the package. This complies with the SoC principle.

From a semantic point of view, packages represent a context for declarations, which is one level above the contexts of an ABAP program. Unlike the contexts of an ABAP program (programs, classes, procedures), a package does not generate a separate namespace.

The namespace for repository objects is defined as follows:

Rule

Clarify the type and affiliation of repository objects in names

Use common naming conventions for repository objects. The predefined name prefixes, CL_, IF_, and CX_, apply to objects of the class library. If possible, create all repository objects in the prefix namespaces only. In addition, use a naming convention to clearly indicate which package or component the objects belong to.

Details

Classes and interfaces are the most important entities for programming with ABAP Objects. To type an object reference, you can use either a class type or an interface type. It is useful to uniquely flag these two types in the class library by means of a prefix. Global exception classes should also be uniquely identified by a prefix. The following naming conventions apply. These conventions are sometimes enforced by the Class Builder but are sometimes only evaluated:

In addition, the names of all repository objects should clearly identify the package or component they belong to. Technically speaking, a package does not generate its own namespace and therefore naming requires strict discipline. Using prefix namespaces is very helpful in itself. However, they are not intended for the package level but for bigger development projects, which usually comprise numerous packages.

Therefore, the names of the repository objects contained in a package should be labeled with a shared name component, which indicates the affiliation to a package or at least to an application component. The length of names is restricted to 30 characters or less, and the namespace prefix is included. Therefore, you should use an abbreviation for this name component and not the complete package name.

You should never assign a universal name for a package-specific or component- specific repository object. This would render the name useless for further general use. For example, general names of the SAP namespace (such as CHAR60 for a data element or CL_ABAP_MATH for a class) should only be declared in absolutely fundamental basis packages delivered by SAP and exposed by these packages in a generally available interface.

If developers find a repository object with a universal name, they naturally assume that they can freely use the object in the way indicated by the name. Before the introduction of the operational package concept, there were no strict checks for package limits. As a result, repository objects with overly universal names (particularly in the SAP namespace and also in the customer namespace) are now used throughout all AS ABAP packages. This can lead to considerable difficulties if you want to implement real package encapsulation.

Note

The above rule supplements the universal rule regarding descriptive names. With regard to technical information in repository object names, the same information stated in section on descriptive names also applies here (also refer to the discussion on prefixes and suffixes in program-internal names).

All development organizations are free to create own naming conventions on the basis of the above rule regarding descriptive names. However, note that the use of a namespace prefix only leaves limited space for the remaining name components. For example, the names of database tables are restricted to 16 characters. Therefore, the namespace prefix should not be too long. It should simply describe a product line using an abbreviation

Exception

Not all repository objects can be created in prefix namespaces. Authorization objects and type groups are typical examples. In these cases, you should create an additional package that includes all of these objects. The object names and package names should, if possible, contain a relevant, normal prefix instead of the real namespace prefix /.../.

A similar guideline applies if further development is performed in areas that are traditionally located in the SAP namespace or the customer namespace. Instead of using a real namespace prefix, you can simulate this by using uniform prefixes when you create new packages and development objects.

If the ABAP Workbench itself allocates names, for instance, for Include programs, which are assigned to specific main programs (such as function groups or class pools), this name allocation always has priority over all other rules. This ensures that the Workbench and the Compiler run correctly.

Example

Refer to the repository objects of the sample application in the package SABAP_DEMOS_CAR_RENTAL.

The subpackages of the SABAP_DEMOS_CAR_RENTAL package start with the same name as the superpackage (as recommended in these guidelines). A suffix indicates their specialization. The same applies to the package interfaces. Instead of a real namespace prefix, the repository objects of the packages have the DEMO_ prefix. This indicates that the objects are part of a demo package. The affiliation to the car rental application is indicated by the abbreviation CR (car rental).