skip to Main Content

Dev Tip: Keep code methods or functions as short and generic as possible

In case you’ve missed our dev tips in past weeks, we will be posting them in the blog moving forward. To sign up and get your dev tips delivered to your inbox each week, click here!

Tip of the Week

Keep methods or functions as short and generic as possible. Not only will unit testing be easier, it will also make figuring out what that piece of code is supposed to be doing easier.

  1. Classes should have one responsibility because you won’t remember all the stuff it does.

    • They should be named something meaningful to what it does.

    • They should have a limited number of they can do because… it should have only one responsibility.

  2. Classes should not include methods that don’t describe what is the responsibility of that class. For instance, a Gateway ABAP Data Provider Class should provide data. But more often than not, you will see something like this that forces you to live inside the DPC_EXT class forever:

 

Here is an example of loading up a data provider class with business logic, that does not belong.

 

class ZCL_SALESORDER_DPC_EXT definition

  public

  inheriting from ZCL_SALESORDER_DPC

 create public.

 …. “ All of the fantastic generated code…

 

private section.

….

methods FIND_SOLD_TO_CUSTOMER

….

methods FIND_SHIP_TO_CUSTOMER

….

methods DO_PRICING_MAGIC

….

methods PRICING_IF_MAGIC_FAILS

….

methods ADD_PRICING_CONDITON

….

methods REMOVE_PRICING_CONDITION

….

methods COPY_SALES_DOC

….

methods CREATE_SALES_ORDER

….

methods FIND_SALES_ORDER

….

 

ENDCLASS.

 

A better example would be:

class ZCL_SALESORDER_DPC_EXT definition

  public

  inheriting from ZCL_SALESORDER_DPC

 create public.

 …. “ All of the fantastic generated code…

 

 private section.

….

methods GET_CUSTOMERS

….

methods GET_MATERIALS

….

methods GET_SIMULATED_SALES_ORD

….

methods GET_SALESORDER_NUMBER

….

ENDCLASS.

 

THEN have classes for each object you’re trying to represent.

 

  1. Methods or functions should be small and descriptive of purpose. This keeps code tight, easy to understand and easy to identify if a unit test fails.

 

//Example of a function that checks if an order is a simulation if there is an order number:

function isSalesOrderASimulation(sapOrderNumber) {
if(!sapOrderNumber) {
return true;
}
}

 

//Example of a corresponding unit test to verify that

describe(‘isSalesOrderASimulation’, function() {
it(‘should return true if the SAP Order number is blank, function() {
var sapOrderNumber = ”;

var result = isSalesOrderASimulation(sapOrderNumber);

expect(result).to.be.true;
});

});

If you have an interest in viewing similar content, visit our blog, here

View our LinkedIn, here

Andy has over 17 years in guiding IT Leaders to achieve their digital objectives. From implementing and integrating SAP business systems, converting complicated business challenges into lean digital solutions, and crafting transformational strategies among the top tiers of the Fortune 500. Andy has expertise in leveraging diverse digital platforms and ecosystems across various industries.

Back To Top