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.
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)
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;
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).
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.