Reports still writing directly to the screen are very hard to maintain whenever changes to the layout are required. On such occasions, review the code and, if the effort involved is not too big, consider converting it to ALV. Always involve the functional people in this decision.
Historically ABAP programs tend to grow very loooong. All programming best practices teach us there is not a single advantage in this approach. If any routine, be it a program, a method, a function or anything else, becomes longer than 200-300 lines, question it and seriously consider refactoring it into several sub-routines. This has the added advantage of potentially increasing code reuse. But the greatest advantage is encapsulation, isolating variables in their local context, instead of having all of them together, resulting in safer and more readable code. The Official ABAP Programming Guidelines book advises this in its chapter 2.2 KISS (pages 32-34). https://help.sap.com/abapdocu_731/en/abenencapsulation_guidl.htm
If the same piece of code is repeated at least once, question yourself why and try to avoid it by creating a reusable routine. If there is more than one SELECT for the same table in a program, make sure you can’t merge them into a single one. Sometimes a smart use of RANGEs to unify parameters can avoid the need for multiple SELECTs. If the same code is used in 2 different programs, don’t repeat the code. Instead, create a class for it which can be shared by both and move the reused code to the common class. https://abapinho.com/en/2012/06/mais-ranges-menos-selects/
The more global variables a program has, the most obscure it becomes. Please avoid them. This is a basic rule of good programming and should always be followed. Even if several variables have to be passed by parameter, it takes slightly more effort but yields a much more readable and safer code. Exceptions can be made for simple reports which run around a single internal table, which can be declared globally without compromising clarity.
It is common to find an ALV data structure explicitly defined in the code. If this is done, the field catalog has to be manually constructed. If a predefined structure (from DDIC or declared as a TYPE) is used instead, the field catalog can be automatically built. This approach is always better and results in less code, even if the field catalog needs to be adjusted here and there. https://abapinho.com/en/2011/12/automatizar-catalogo-alv/
Many times we do READ TABLE itbl or LOOP AT itbl just to do a CHECK SY-SUBRC = 0. In these cases, the actual data read is not needed. For these cases always use TRANSPORTING NO FIELDS. This way is faster and avoids having to declare a target structure.
In classes, consider using exceptions classes over the old ones. These have great advantages and, once understood, are simple and allow for simpler code.
In reports, instead of WRITE TEXT-001, use WRITE ‘bla bla bla’(001). This way a default text will always be there and besides the readability of the program is improved. https://abapinho.com/en/2011/11/programas-poliglotas/
SALV classes are more versatile and more recent than the old function modules. So, for new ALVs always use SALV. The only exception is editable ALVs which SALV classes are still very incapable of doing. https://scn.sap.com/docs/DOC-10365 https://scn.sap.com/docs/DOC-10366
Since data operations are much more optimized in the database server than in ABAP, it is always better to use the first as much as possible. FOR ALL ENTRIES should only be used when INNER JOIN doesn’t give us what we need or is not possible (like with BSEG for example). Artificial ranges are also a possible alternative to FOR ALL ENTRIES but be careful not to reach the SQL parser limit. It depends on the database server but as a rule of thumb avoid ranges with more than 1000 lines. When using FOR ALL ENTRIES always make sure the internal table is not empty or else all lines of the database table will be fetched.