Introduction

Recently I was reading about software metrics for a customer project. In particular I looked at the cyclomatic complexity (aka McCabe complexity) and the Halstead complexity. There are known issues with different complexity measures as well as limitation to their applicability. Nevertheless, those metrics can provide additional information regarding the complexity and maintainability of software.

What I wasn’t aware before is, that the Code Inspector (transaction SCI) already offers quite software metrics out of the box. In the remainder of this block I show how to configure the Code Inspector to calculate the delivered software metrics.

Creating a Software Metrics Check Variant

In order to calculate software metrics using the Code Inspector the first step is to create a check variant. Be sure to create a global check variant. Only global check variants can later be used from within ADT. For this blog I created a check variant named Z_SOFTWARE_METRICS.

In this check variant I only activated the checks in the “Metrics and Statistics” group.

Furthermore, I set the reporting to “Show metrics”. There reason is twofold. First, I wanted to see that the software metrics are calculated and what the actual results are. Second, the default thresholds for any warning are so high, that you’d have to write really really complex (i.e. bad) code in order to trigger the warnings. Of cause it would have also been possible to lower the thresholds for the warnings.

However, this didn’t have the expected result. The calculated metrics where not displayed. Therefore, I change the reporting to “Show warnings” and the threshold to 1 for all metrics.

Triggering the Calculation of the Software Metrics

After the check variant is created it is now possible to trigger the calculation of the software metrics in the ADT. To do this right click on the object (program, class, package) for which the metrics should be calculated. In the context menu select “Run As” → “ABAP Test Cockpit with…”

This opens a popup windows in which the check variant can be selected. Note that this window support search and completion using the <ctrl>-<space> shortcut. So simply type Z and trigger the search to select the required check variant.

For this blog I recreate one of the famous counter examples of the cyclomatic complexity metric, a case statement mapping the numbers 1 to 7 to weekdays. Below is the the complete source code of the example.

CLASS zcl_mccabe_example DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .

  PUBLIC SECTION.
    METHODS day_of_week IMPORTING i_day_number      TYPE i
                        RETURNING VALUE(r_day_name) TYPE string.
  PROTECTED SECTION.
  PRIVATE SECTION.
ENDCLASS.


CLASS ZCL_MCCABE_EXAMPLE IMPLEMENTATION.
  METHOD day_of_week.

    CASE i_day_number.
      WHEN 1.
        r_day_name = 'Monday'.
      WHEN 2.
        r_day_name = 'Tuesday'.
      WHEN 3.
        r_day_name = 'Wednesday'.
      WHEN 4.
        r_day_name = 'Thursday'.
      WHEN 5.
        r_day_name = 'Friday'.
      WHEN 6.
        r_day_name = 'Saturday'.
      WHEN 7.
        r_day_name = 'Sunday'.
      WHEN OTHERS.
        r_day_name = 'unknown'.
    ENDCASE.

  ENDMETHOD.
ENDCLASS.

The following screenshot shows the code of this example as well as the result of calculating the software metrics. Markers were added to some of the lines (e.g. 1, 15 and 17).

Detailed results of the calculated metrics are shown in the ATC Problems view. For the example the calculated cyclomatic complexity is the expected 8. Furthermore, also the Halstead metrics were calculated.

Happy measuring.
Christian