Another ingenious tool has been available for some time now from the pen of Lars Hvam, the inventor of abapGit. It’s called abapLint. With this tool it is possible to carry out static syntax checks of ABAP source code – without an SAP system! But one after another…
What is a Linter?
The SAP programming world is its own multiverse in which a lot of things are done differently than in other programming languages and development environments. Since I have worked almost exclusively with SAP since completing my training as a software technology consultant, I am unfamiliar with many terms from the “normal” development world. When I first heard the term “linter” in connection with abapLint, I had to look up what it could be.
For all those who are equally perplexed by the term linter, a quick trip into the past: Linter were invented to compensate for the weaknesses of the compilers of the time. On the one hand, the compilers demanded error-free coding, but on the other hand, they did not recognize important dependencies. In addition, the compiler didn’t care what the source code looked like. The lint program was originally developed for C and carried out extended program checks. The term was then also used for other programming languages.
A linter performs static analysis and detects formal errors. So exactly what the ABAP syntax check does. The ABAP compiler’s checks are sufficient to ensure that a program is free of syntax errors. However, you always need an SAP system for this.
However, since many important things are not recognized by the syntax check, SAP provides additional tools, such as:
- The extended program test SLIN
- The code inspector
- Package checks
Typical errors that do not matter to the syntax check but lead to problems with program execution are, for example:
- Incorrect parameter name when calling function blocks
- The message number used does not exist or has a different number of parameters
What does abapLint do?
If SAP already provides a lot of help for comprehensively checking programs and classes, why do I need abapLint?
abapLint is an open-source project. This means that everyone can participate and contribute further tests. While the SAP tools are primarily limited to functional tests, abapLint offers a variety of rules that focus on the readability and standardization of source text. Various checks indicate when standardized code formatting has not been adhered to.
The rules are closely based on SAP’s Clean ABAP style guide. These are exactly the checks you look for in vain in the SAP tools.
Examples of checks that abapLint carries out regarding clean code:
- Note if the EXPORTING keyword can be omitted when calling a method (EXPORTING can be omitted)
- Make sure there are no spaces between the last command and the final dot (Space before dot)
- Prefer NEW construct over CREATE OBJECT (Use NEW)
Other helpful rules:
- Avoiding Yoda expressions (No Yoda Conditions): IF 0 = sy-subrc
- Ensure that an authorization check is carried out before a call transaction (Call Transaction Authority Check)
- Prefered Inline Declarations
- Find unwanted statements (Avoid use of certain statements). For example, the check can be turned on so that table declarations WITH DEFAULT KEY are found. The statement makes no sense for standard tables. It is better to use WITH EMPTY KEY when the key is not needed.
The available rules (currently 163) are documented and can be tried out online on the abapLint playground.
Use on github
abapLint integrates into the github interface. A small, inconspicuous “X” indicates when checks have failed:
checks have failed:
You can click on the X and You will then receive a list Details of failed checks:
The file abaplint.json, which must be in the main directory of the repository, can be used to set which checks should be carried out.
Differentiation from ABAP-Cleaner
The open-source project ABAP Cleaner is partly in the same vein as abapLint. It finds constructs that are not desired according to the clean code guide and fixes them immediately. The ABAP Cleaner is a pure Eclipse plugin and therefore follows a different approach than abapLint.
Differentiation from SAP-Code-Pal
The open source project SAP Code Pal also aims to improve code quality. The project is available in Github and imports additional checking rules into the code inspector that can be activated there.
abaplint.app
The open source project SAP Code Pal also aims to improve code quality. The project is available in Github and imports additional checking rules into the code inspector that can be activated there.
abaplint.app
All publicly available ABAP repositories from github.com are listed at the Internet address https://abaplint.app/stats. The app shows what additional options abapLint offers. The issues that apapLint found are listed for each repository.
Access to public repositories with the abapLint app is free of charge. If you want to use the app for private repositories, a fee of currently $19 per user per month is required, which must be paid via the Github account
There are interesting key figures for the repositories such as:
- Method Length
- Method complexity
The method length clearly shows how many methods there are and with how many statements. The methods are listed below in the graph, descending according to the number of lines. The following example comes from the ABAP2UI5 project:
When refactoring, it makes sense to start with methods with many statements, as there is a very high probability that individual blocks of statements can be swapped out.
I find the compatibility perspective very interesting. This shows which SAP releases the source code is compatible with
Here is an example from:
The instructions that are incompatible with the release are listed below the diagram.
I also find the Void Types overview helpful, which lists the data types used. Additionally, information is shown here about whether the data types are released for the cloud or marked as obsolete. If there is an official successor, that will also be listed. Here is an example of the coding of our ABAP cookbook:
The key figures average complexity and average method length are also very informative and a good indicator of how a project is developing. The following screenshot from the ABAP2XLSX project nicely shows that the average method length has decreased over time:
An indicator that code quality has improved.
A relatively new addition is the Intra Class Call Graph, which shows a sequence diagram within a method. Here is another example from the ABAP2XLSX project:
Was that all?
Not at all. It has just started here. With the abapLint initiative, Lars has created his own universe with many possibilities. This is how it continues:
- Integration of abapLint in VSCode
- ABAP statement diagrams for each command
- abapLint Transpiler: Execution of ABAP code in the browser using Javascript
The abapLint transpiler makes it possible to run ABAP on a Raspberry Pi, or for ABAP to be available as a language on Exercism.
If you are interested in further developments, then follow Lars on LinkedIn. He posts interesting subjects about ABAP programming at irregular intervals.