Thou shalt use exception classes
In classes, consider using exceptions classes over the old ones. These have great advantages and, once understood, are simple and allow for simpler code. https://zevolving.com/2011/12/class-based-exception/
In classes, consider using exceptions classes over the old ones. These have great advantages and, once understood, are simple and allow for simpler code. https://zevolving.com/2011/12/class-based-exception/
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
We start with two variables:
DATA word1 TYPE string.
DATA word2 TYPE string.
DATA: phrase TYPE string.
word1 = ‘this’.
word2 = ‘that’.And we want to concatenate them adding the word “plus” between them and, of course, separate them by space.
In Greek mythology, the gods’ most commonly used means of communication with mortals was rape. They would rape for no reason whatsoever.
The closest thing we have to rape in ABAP is the command “SUBMIT”, which is also the most common way of communicating between two programmes.
The ABAP editor has many curious functionalities. You can even write in multiple lines at the same time.
It’s not.
But they - the people who make and remake the ABAP itself - are trying to mend this unfortunate situation.
Look at this new functionality:
Did you know that you can do a LOOP on an internal table of one type into a structure of a different type?
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.
User-exits (and enhancements) are usually crowded with CHECKs. The tragic consequence is that, if the check fails, nothing else after it will run. Not even the standard code. Always try to correct these. Encapsulating the code inside a routine (ideally a method) is enough to render it harmless.
When declaring structures which will receive data from an internal table, instead of declaring its type directly, use LIKE LINE OF. This way not only it becomes clear that they are related but also, if you happen to change the type of the internal table, you won’t have to worry about updating the structure’s type.
I keep learning new transaction commands. Today I learned some which solve a problem which, although rarely, has happened to me in the past.
Did this happen to you? You make a change to a text of a data element you’re using in a table to be edited through SM30. But when you go and edit that table in SM30 the old text is still there. You activate objects, close windows, open windows, no matter what you do, the new text is not shown.
Never do COMMITs inside user-exits. Also, make sure any external routine you call from there doesn’t do any COMMIT either.
Of course you already know the “Model” button in the ABAP editor that allows you to automatically add models for function modules, calls for methods and others.
The new editor has now grown a bit (it’s now only 10 years behind Eclipse instead of 20) and it allows you to automatically complete some commands through the CTRL-SPACE shortcut.