All your ABAP prefixes are belong to us

[larshp]

Prefixes

Prefixing variables in ABAP is a hot topic, and during the years there have been many interesting discussions:
https://blogs.sap.com/2018/04/30/are-30-characters-enough-to-make-your-code-better/
https://blogs.sap.com/2016/02/05/fanning-the-flames-prefixing-variableattribute-names/
https://blogs.sap.com/2009/08/30/nomen-est-omen-abap-naming-conventions/
I find it most important that naming is done in a consistent way, all using prefixes or no prefixes at all.
However, all customers I have worked for recently have prefixing as part of their development guidelines, typically supported by the “Extended Naming Convention for Programs” in Code Inspector/ATC. This blog introduces a new Code Inspector check which can be used for making sure prefixes follow the development guidelines.

abapOpenChecks

abapOpenSource is an open source project which provides extra checks for Code Inspector/ATC, a lot has happened since it was initially released 3 years ago. The number of checks has increased from 26 to 69, and a lot of false positives been removed from the results. All checks have different use cases and vary in quality. I recommend trying it out, the checks are widely configurable, and it is possible to cherry-pick the most useful checks.

All your prefixes

The latest check “Naming Conventions” can check prefixes for variables in ABAP and report the findings to the developer.

When reporting findings, the check reports the expected prefix so the developer will not have to look up the conventions or the type of the variable,



As part of the check configuration, it will by default ignore most of the naming in exception classes, as it sometimes is not possible to have these follow the conventions. Also, special function module signatures are ignored, like conversion exits where the parameters are always INPUT and OUTPUT,



Overall it should report less false positives, and if there are false positives, it is possible to inherit from the check class and implement custom rules or give back to the community via a PR on GitHub.

As always, bug reports and suggestions welcome