ABAP - Naming conventions
How important is it nowadays to adhere to naming conventions or even to use naming conventions in the modern ABAP environment? We want to look at that in this article.
Table of contents
In this article we want to take a look at the topic of naming conventions and how they should still be dealt with today. Are these conventions still up-to-date at all or should they, like form-based reports, be revised sometime?
Clean ABAP
With Clean Code or Clean ABAP, SAP is slowly trying to bring a little more order into the ABAP code and, in our opinion, this is also important in order to get rid of a lot of old baggage from the past. In addition, unit tests with ABAP units have been on the rise for years and web technologies such as REST services and ODATA interfaces are increasingly determining the picture of the modern landscape. So-called microservice architectures are proof of not having monolithic systems with all functions, but of providing services that can then be consumed.
With the manifest, SAP would like to give you tips on how you can write clean source code in the future, rely on the modern principles of object orientation and how you will use the naming conventions in the future.
Naming convention
In the document in the chapter "names" it is described that you should no longer use Hungarian notation or other encodings. In addition, SAP provides a whole subpage, why you don't need these conventions and why you shouldn't rely on any convention. From this the three points are summarized:
- Old relic - Code was often printed out and read in the past, but the aim was to avoid searching for variable definitions or scrolling through and see each variable to see what type of data it was and what its purpose was.
- Length - There are limits to the length of certain types and names so that you cannot always give a descriptive name. So you would save a few characters in order to assign your desired name.
- Name clashes - Pay attention to name clashes of variables (see more below).
What else is there to consider? ABAP unfortunately does not support CamelCase, such as "getCompanyCode", but you have to work with underscores and get "get_company_code". Not necessarily a negative aspect, but developers from other areas will initially be offended by the legibility.
Namespaces
But actually, as an ABAP developer, you are always bound to the SAP namespace and can only use the approved namespaces. So you can typically only create objects in the Y or Z namespace and thus have a specification as to how your objects must begin. Likewise, if your company has its own namespace like "/NSPC/", then you are first bound to this.
You then have your freedom within the objects and the chapter on how to name and use your variables and interfaces within an object also relates to this for the most part.
Reasons
What about the advantages and disadvantages of using the respective alternative? In the world of development, most languages have no naming conventions and you can tell the type and use by the name and the appropriate developer tools.
For naming convention
- Provide clear guidelines for the basic naming of variables and interfaces, so that even "lazy" colleagues have to bring a certain routine with them.
- They can be automatically validated with the help of the ATC, which would not be possible with free naming without a review.
- Already included in the developer's standard routine.
For Clean ABAP
- Meaningful code and avoiding abbreviations, which makes the code more readable without many comments.
- State of the art development in many other languages.
- Support from the ABAP Development Tools (ADT) to determine the typing.
Name clashes
What about name clashes of variables then? A name clash is the case when a variable is defined locally that has the same name as a variable in the global context. Then, depending on the type of object, you can no longer access the global variable, but only the local definition. Here is an example:
CLASS zcl_bs_demo_shadowing DEFINITION PUBLIC FINAL CREATE PUBLIC.
PUBLIC SECTION.
INTERFACES if_oo_adt_classrun.
METHODS:
constructor.
PROTECTED SECTION.
PRIVATE SECTION.
DATA:
name TYPE string,
age TYPE i.
ENDCLASS.
CLASS zcl_bs_demo_shadowing IMPLEMENTATION.
METHOD constructor.
name = 'John Doe'.
age = 18.
ENDMETHOD.
METHOD if_oo_adt_classrun~main.
DATA(name) = 'Jane Doe'.
DATA(age) = 20.
out->write( name ).
out->write( age ).
ENDMETHOD.
ENDCLASS.
In the constructor we initialize the variables "name" and "age", which are then available as members in the object. In the main method we define local variables with the same name and assign their own values. From this point on, we can no longer access the variables using the same name and "Jane" is then displayed in the output. In order to be able to access the global variables again, you have to work with the self-reference.
out->write( me->name ).
out->write( me->age ).
At this point you will probably think to yourself that this would not have been a problem with the appropriate notation. The members start with M and the local variables with L, so this problem would not arise in a world with naming conventions.
Conclusion
Currently, the use of naming conventions is still set in many companies, the ABAP Test Cockpit (ATC) automatically supports that the rules are adhered to. If more and more developments are based on the Clean ABAP approach in the future, this has to be secured primarily by trained developers and code reviews, otherwise the code quality will suffer.
Source:
Clean ABAP (Github)
