Category > Best practices
Supported by
Supported by Inetum

Thou shalt use a constants table

images/thumbnail.jpg - Thumbnail
Whenever you feel a constant value can change and you can’t add it as a user parameter, store it in ZCONSTS. This table should never be used directly. Instead, a class like ZCL_CONSTS should be created to properly access it, like shown in this article: (portuguese only) Resist the temptation of using T900 or similar tables for this purpose. It’s true that a lot of people do it. But it’s ugly, durty and besides these tables don’t even have an adequate key because they were not designed with this in mind.

Thou shalt build up and adopt toolkits with common tools

images/thumbnail.jpg - Thumbnail
Code which is used very often should be made available centrally, if possible under a single package (ex: ZTOOLS) so that it’s easily identified. There is a lot of code already available on the Internet to accomplish several common functions (ex: ABAP2XLSX). Adopt it; For your most common tasks, develop your own tools which you can reuse and add them to the central library; Advertise the existence of that library among your colleagues to avoid that they waste time come up with duplicate code wasting;

Thou shalt not REPLACE ‘.’ with ‘,’ just like that

images/thumbnail.jpg - Thumbnail
If you need to adapt the content of a file with amounts, always take into consideration the user settings (USR01-DSCFM). If you need to convert a string to a number use FM MOVE_CHAR_TO_NUM. If you need to convert a number to a string use WRITE curr TO str [CURRENCY waers].

Thou shalt use command TABLES only when unavoidable

images/thumbnail.jpg - Thumbnail
Using SELECT-OPTIONS is one of the very few reasons for using TABLES. For all other cases, explicitly declare a local variable for the equivalent structure. TABLES basically creates obscure global variables which increase ambiguity in the code. And global variables should be avoided anyway.

Thou shalt use FIELD-SYMBOLs instead of working areas

images/thumbnail.jpg - Thumbnail
READ TABLE itbl ASSIGNING is always faster than READ TABLE itbl INTO wa. Besides, when making changes to internal tables, not only it doesn’t require the explicit MODIFY but it also does away with the auxiliary TABIX variable. The only situation in which a working area is better is when adding new lines to an internal table. Some people contend that working areas should still be used when no changes are to be made to the data.

Thou shalt group related parts together

images/thumbnail.jpg - Thumbnail
Sometimes you find an IMPORT in the code but you have no idea where the corresponding EXPORT is. When communication is needed between programs, it should be done using a pair of methods belonging to the same class. This way, when we run into one, we’ll always know where the other one is. Anyway, try to use EXPORT/IMPORT only when unavoidable. If possible, use static class variables instead.

Thou shalt avoid dynamic messages

images/thumbnail.jpg - Thumbnail
When you need to send a dynamic message by parameter, make sure you still use the MESSAGE command, so that the “where-used” doesn’t loose track of it. When you do MESSAGE E001 INTO V_DUMMY, the message details become available in the system variables: SY-MSGNO, SY-MSGTY, etc. Also, message texts should never be hardcoded, they should always be defined in SE91. https://abapinho.com/en/2009/09/evitar-mensagens-dinamicas/ (portuguese)

Thou shalt not use direct code in user-exits

images/thumbnail.jpg - Thumbnail
All code to be put in user-exits (BADIs, enhancements, SMOD, etc.) should be encapsulated. It’s common for an user-exit to include multiple independent parts. Each of these parts should be encapsulated in its own method. Even if it is only one line; This should apply to both new implementations and changes to existing code; A change to existing code should always be seen as an opportunity to organize existing code into methods, since it will have to be tested again anyway;

Thou shalt not implement in classical processing blocks

images/thumbnail.jpg - Thumbnail
Official ABAP Programming Guidelines (page 34): [When a classical processing block is required], you should immediately delegate the execution to a suitable method (see Rule 6.37, No Implementations in Function Modules and Subroutines, and Rule 6.44, No Implementations in Dialog Modules and Event Blocks).

Thou shalt use ABAP OO whenever possible

images/thumbnail.jpg - Thumbnail
All new developments should be implemented using ABAP Objects unless still impossible (RFC, IN UPDATE TASK, screens, etc). Existing developments, when rewritten, should also be converted to OO, if it proves to be realistic. Official ABAP Programming Guidelines (page 32) rule 3.1: Use ABAP Objects whenever possible for new and further developments. Classical processing blocks may be newly created in exceptional cases only. pdf/why-abap-objects.pdf https://scn.sap.com/people/thomas.jung/blog/2007/12/19/update-your-abap-development-skills-to-sap-netweaver-70 https://wiki.