SAP ABAP Training Institute In NOIDA

NIDHI FUTURE LABS TECHNOLOGY
3 min readJul 29, 2021

With respect to structuring, coding CASE has a clear advantage over a set of IF statements because the CASE statement reduces the amount of checks required and produces well-structured code. However, CASE must be handled with care, otherwise well-structured methods contradict a well-structured architecture. We will walk through the various uses of CASE for ABAP development in this blog post.

case or IF
There are two main advantages to the syntax of CASE for clean code over IF statements. While a CASE statement can always be replaced with a set of IF blocks, the opposite is not possible, as the CASE statement only checks a single variable for specific values, whereas in an IF statement, any type of condition and combined Conditions can be checked. .

As a result, CASE statements should be preferred whenever possible and useful. By design, the CASE statement creates a structure within the method that is easy to follow because each handled case is introduced by a new WHEN block. All comparisons to be performed have an implicit positive phrase because the only operation is a comparison of equality. That way, you won’t have inversions or other negatives, making it easier to follow the control flow.

CASE statements work especially well with enumerations or similar value sets. They contain a well-defined set of possible cases that define a possible WHEN block. Additionally, CASE can be easily extended by adding a new WHEN block when the count is incremented or a new condition is added to the scope. Since this approach is minimally invasive in other cases, the probability of introducing error is quite low.

Even though the CASE statement provides a nice structure, these statements contain more logic within the method than to identify the relevant case and delegate further processing to another method. This scenario contradicts the single-responsibility principle because there is more than one reason to change this method. Changes must be made when another case is added and the procedure for one of the covered cases changes. The list below shows an example in which the single-responsibility principle is not considered.

case vehicle_type.

When ‘train’.

duration = wait + distance / speed + stop * wait_at_stop.

When ‘Plane’.

Duration = wait * 2+ (distance/speed).

When ‘car’.

Duration = Distance / Speed.

Endcase.

In this example, whenever a new Vehicle type is added to the scope, the method has to be changed. Additionally, when a change is made to the calculation of the duration (for example, to include slowing down before a stop), the method must also be changed. Thus, there exists more than one reason for the change. In short, a method should hardly do much more than matter. For this principle to be considered, each WHEN block must simply be delegated to some other method implementing the computation, as shown here.

case vehicle_type.

When ‘train’.

duration = count_train_duration().

When ‘Plane’.

duration = count_plane_duration().

When ‘car’.

duration = count_car_duration().

Endcase.

With the last change, the method is identifying only relevant cases and processing representations accordingly. However, in this example, all of our calculations are relatively simple; Depending on the decision processing, the code can be quite complex. Furthermore, it is easier to test the case method separately from the actual calculation because there will be fewer cases to consider.

case or switch
Sometimes, a CASE block is used only to specify a specific field value to a more general one, perhaps because the type is no longer relevant or to fetch a single value for the user. For this purpose, the switch operation was introduced, which can act as an inline assignment, as shown below.

data(id_to_display) = switch string(id_type.)

when ‘employee’ then partner-employee_id

when ‘EXT_WORK’ then partner-assignment_id

when ‘customer’ then associate-customer_id

throw else unknown_types().

Like other operators, switch can also be used inline, for example, for method parameters that allow the result of the switch to be changed. The same rules apply for other operators. It may seem convenient at first to use the inline options whenever possible. Unfortunately, a non-trivial assignment to a parameter can result in difficult code to follow and maintain.

The previous assignment is not complicated and covers only three possible values ​​for id_type. Nevertheless, the statement uses multiple lines and, when embedded in another method call, is hard to follow. Switches can save space and reduce the number of statements when they don’t add value. However, you can easily overuse this operator, and in general, you should not use SWITCH within another functional call. Instead, the result should be stored in its own variable, thus

Read More

--

--

NIDHI FUTURE LABS TECHNOLOGY

Future Labs Technology is an emerging world-class SAP Training Institute in Delhi NCR for all inspired SAP aspirants in Delhi-NCR passionate