I'm always struggling in finding the right way to code, even more after 25 years of ABAPing. So I listen to speeches on youtube, read books about programming style and - last but not least - enjoy discussing the various principles of good programming in this place here.
In this blog post, I'd like to present some of my own "golden" rules in coding ABAP, hoping you will join me writing your own rules into the comments (or busting my rules with your knowledge...)
So, here we go
- Use Model - View - Controller architecture
You never know if your application should run on Fiori tomorrow - so split the data manipulation logic from the presentation using this pattern
- Avoid using class attributes
Class attributes are global variables. If you set use them in your methods, your program decreases in legibility.
- When using class attributes, access them only in public methods
You can't always avoid class attribute. In a model that serves a front end, you have to keep your application data in attributes. However, if you are calling methods to manipulate this data, pass everything that's an attribute as parameter. Your methods remain pure (processing only what's been passed by parameters) and understandable
- Keep methods small
It's so comfortable to read through a logic that spans only one page on the screen. So, as soon as my method becomes larger, I think about meaningful possibilities to split the logic in more methods.
- Isolate database accesses
If you see that you have to read another customizing table in the middle of the logic of your coding, you may think about a small line "select * from tvbur....." just to get the data. So maybe a method "sales_totals = calculate_totals( sales_documents )" has some SQL statements that a reader of your program would never expect. So I try to put all the DB accesses apart. One good way for this are data provider classes (see https://blogs.sap.com/2017/10/31/the-global-variable-dilemma/).
- Use meaningful descriptors
A not-so-long time ago, I used to code things like "lv_matnr1 = get_sup_dum_comp( lv_matnr1 )". Now I have to maintain these programs - what a mess. Nowadays, I'd write "superior_dummy_material = get_superior_component( component_material )". I sacrificed the prefixes for more meaningful variable names.
- Avoid changing variables
This is a principle I took over from the functional programming paradigm. First, it confused me - aren't variables made to change them? You'd be amazed how rarely you really have to change variables, and the new declarative additions that came with ABAP 740 are supporting this functional way of coding. The reason for this is of course again legibility. See the little example
header_material = order_header-matnr.
headline_text = read_material_description( header_material )
component_:material = order_component-matnr.
component_text = read_material_description( component_material ).
instead of
lv_matnr = order_header-matnr.
headline_text = read_material_description( lv_matnr )
lv_matnr = order_component-matnr.
component_text = read_material_description( lv_matnr ).
where a variable is being reused.
Best regards
Jörg
