Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 
BMEIJS
Active Participant


In my previous blogs about Method Chaining (http://scn.sap.com/blogs/ben_meijs/2013/05/08/using-new-abap-stuff-method-chaining-and-clsalvtable, and character string processing ( Using New ABAP stuff – new options for Strings) , I have given examples of how these new WAS702 options, when used properly, allow for a decrease in ABAP size without compromising the readability of the code. However, decreasing code size is not an aim in itself, only part of the bigger challenge to make code more maintainable, which deserves a (series of) blog(s) for itself. This blog gives an example of how a specific use of the new operand EQUIV can make code less readable in my opinion.

 

What’s it al about?


In ABAP for WAS702, SAP has introduced a new Boolean operator EQUIV.  This operator is used for linking two logical expressions, thus creating a new logical expression, which is true if both logical expressions are true or if both are false.

Imagine that you have two internal tables for which you need to check if they are both empty or not. Using EQUIV, this could look like this:

IF lines( itab1 ) = 0 EQUIV lines( itab2 ) = 0.
"Both ITAB1 and ITAB2 are populated OR both are empty!
ENDIF.


By negating an expression that uses EQUIV, if can be checked if only one expression is true. Using this, the exclusive OR (XOR) has now become available to ABAP-programmers.

IF NOT lines( itab1 ) = 0 EQUIV lines( itab2 ) = 0.
"XOR: itab1 is empty and itab2 populated, OR itab1 populated and itab2 empty.
ENDIF.


Note that with EQUIV you can only link two logical expressions.

EQUIV and Readability – an example


The example that I’m using in this blog is loosely based on some real life ABAP code for checking user input of parameters and select-options. I have simplified the original code in order to make this example easy to understand.

Imagine a selection screen containing radio buttons and select-options. If one radio button is selected, one select-option must be populated and the other must be empty. The same applies to a second radio button.

The selection-screen is generated by this definition:

PARAMETERS: pa_1 RADIOBUTTON GROUP rad1,
pa_2 RADIOBUTTON GROUP rad1.
SELECT-OPTIONS: so_pa1 FOR sy-datum,
so_pa2 FOR sy-uzeit.


As you would expect, I use the AT SELECTION-SCREEN ‘event’ to check the consistency of the selection values.

AT SELECTION-SCREEN.

"if PA_1 is filled, SO_PA1 should be filled and SO_PA2 should be empty
"if PA_2 is filled, SO_PA1 should be empty and SO_PA2 should be filled.
IF ( pa_1 IS NOT INITIAL AND lines( so_pa1 ) = 0 )
OR ( pa_2 IS NOT INITIAL AND lines( so_pa2 ) = 0 )
OR ( lines( so_pa1 ) = 0 AND lines( so_pa2 ) = 0 )
OR ( lines( so_pa1 ) > 0 AND lines( so_pa2 ) > 0 ).
MESSAGE 'Only combinations of PA_1/SO_PA1 or PA_2/SO_PA2 allowed' TYPE 'E'.
ENDIF.


The variant below uses EQUIV and NOT EQUIV to reach the same goal.

AT SELECTION-SCREEN.

"if PA_1 is filled, SO_PA1 should be filled and SO_PA2 should be empty
"if PA_2 is filled, SO_PA1 should be empty and SO_PA2 should be filled.
IF  NOT ( pa_1 IS NOT INITIAL
EQUIV lines( so_pa1 ) > 0

"XOR: pa_1 is filled OR so_pa1 is filled. This is NOT ok
OR  NOT ( pa_2 IS NOT INITIAL
EQUIV lines( so_pa2 ) > 0

"XOR: idem for PA_2 and SO_PA2.
OR      ( lines( so_pa1 ) > 0
EQUIV lines( so_pa2 ) > 0 ).

"both TRUE or FALSE means both empty or filled, which is NOT ok
MESSAGE 'Only combinations of PA_1/SO_PA1 or PA_2/SO_PA2 allowed' TYPE 'E'.
ENDIF.


 

By using the EQUIV-variant I have actually reduced the readability of the code. Any combination of NOT, NOT, EQUIV and OR make ABAP-code difficult to understand. I wonder if I will be still capable of understanding this code in 3 months time without the added inline comments, let alone someone else. The first variant has one statement more, but is easier to understand and should be used.

Conclusion


This blog is not an anti-EQUIV pamphlet. Using the EQUIV operator doesn’t have to mean a decline in readability of ABAP Code. However, if I need to write an inline comment for every part of an IF-statement in order to make it understandable, something must be wrong. What do you think?

4 Comments