GUIDELINE 4.1
Uppercase/Lowercase
ABAP_BACKGROUND
In contrast to many other modern programming languages, ABAP is not
case-sensitive for ABAP words (tokens of an ABAP statement that express
its semantics; either ABAP keywords or additions) nor for operators and
names of operands. The only exception is
dynamic programming , where the names
of operands usually have to be specified in uppercase.
ABAP_RULE
No Mixed Uppercase and Lowercase in Names
Use only lowercase or uppercase in an individual token. Use uppercase
for keywords and lowercase for operands.
ABAP_DETAILS
The usage of upper or lower case for tokens, that is ABAP words and
names, used to be a very important aspect for the formatting of the
source code. A uniform adherence to upper or lower case made it easier
for the reader to differentiate keywords and names. Due to the syntactic
source code coloring in the ABAP Editor, this aspect has become less
important; however, the above rule is still valid because of the
following reasons:
Syntactic source code coloring is generally not visible when source code
is printed. Therefore, a uniform rule for using upper and lower case is
useful for emphasizing the difference between keywords and names.
Because the usage of upper and lower case in ABAP source code has no
syntactic significance outside of character literals (that is, text
field literals in inverted commas (#), string literals in back quotes
(`), and character string templates in vertical lines (|)), the ABAP
development environment is not designed to maintain it permanently
outside the mentioned constructs. The Pretty Printer only offers
the alternatives to use only lowercase or only uppercase, or to use
either uppercase or lowercase for keywords and lowercase or uppercase
respectively for names in operand positions.
Because of the second point, it does not make sense in ABAP to use upper
and lower case as a self-defined means of style. In other words, the
names should not be written in mixed case style (also referred to
as camel case style ; see the following example), as is very
popular in languages in which case sensitivity is taken into account. A
consistent notation cannot be ensured due to the missing syntactic
relevance. A mixed notation will be lost sooner or later when the
Pretty Printer is used, even if this is unintentional. Moreover, it
possibly prevents other developers from using the Pretty Printer
after changes have been made to the source code.
Use of the Pretty Printer is
explicitly recommended.
Example
When the program PGL_UPPER_LOWER_CASE
is executed, source code is displayed in the ABAP Editor; the
upper part shows the declaration of a class with names in mixed case
style or camel case style . Here, uppercase marks the
beginnings of words within a combined name.
The code provided here as a bad example approximately follows the Java
convention, and in the eyes of many beholders it might look better than
the following good example. However, its appearance is less important
than the mentioned technical restrictions, which do not currently allow
such a naming. Executing the Pretty Printer would irreversibly
spoil the code's appearance because the names would then be illegible.
The lower part of the source code shows the declaration of a class in
ABAP style, where which words within combined names are separated by
underscores (_). These separations cannot get lost when you use the
Pretty Printer .
Once the program has been called, the example is formatted according to
the proposed Pretty Printer
setting , with ABAP words in uppercase and operands in lowercase.
Irrespective of its configuration, the separation of the words in the
names would remain after each execution of the Pretty Printer .
Note
The built-in character string functions, to_mixed and
from_mixed allow conversions between names in ABAP style with
underscores and names in mixed case style or camel case style
, which can be helpful for data exchange with external systems.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved