Skip to Content

Pretty printer is very useful, but in some cases, you have to be a “Pretty coder” yourself.

Especially with ABAP 740, where all those expressions came up and finally made us feel like real programmers – as we now could do things like

data(ls_result) = new lcl_data_processor( new lcl_data_provider( p_matnr ) )->do_something_important( iv_simulation = abap_true ).

just like all the others.

The ABAP statements are getting longer these days, so I asked myself how to distribute them into several lines and keep the legibility. I started with something like

      if line_exists( lt_process[ orderid = ls_queue-orderid
                                  activity = ls_queue-activity ] ).

But when it comes to real deeply nested expressions, this would lead to enormous line sizes. What I am doing nowadays, is more like this:

        rt_res = value #(
          for s_oper in lt_operations where ( sub_activity = space  )
          ( value #(
              let ltext =  actvt_longtext_read( s_oper ) in
              act_end_date          = s_oper-act_end_date
              act_end_time          = s_oper-act_end_time
              act_start_date = reduce d(
                init d = s_oper-act_start_date
                for s_sub in it_sub_oper where (

i.e. increase indentation by bracket level. When closing the brackets, I just do

                    then cond #(
                      when s_subd-isdd < d
                      then s_subd-isdd
                      else d )
                    else d ) ) )

that is closing everything in one line.

Still I’m not totally satisfied with my approach, especially with the closing of bracket levels. But wasting a line for each closing bracket seems ugly to me.

What is your approach in coding very long ABAP statements?

To report this post you need to login first.

14 Comments

You must be Logged on to comment or reply to a post.

  1. Mike Pokraka

    An excellent topic. But I would like to add this predates 7.4, but the new syntax has just complicated it.

    My view is that there is a degree of personal taste and style. I tend to make a little effort to format code nicely, with future readers in mind.

    Too much horizontal information decreases legibility, as does too much vertical. So it depends a little on the content.

    I try not to make lines too long, as people (myself included) should also be able to read it on a laptop or in the debugger. So ‘hanging vertical’ arrangements are OK if the line isn’t too long, otherwise I start to wrap it. The important thing is consistency – putting all grouped bits together.

    "If the line is short
    data(foo) = bar->calculate_something( i_param   = 1 
                                          i_another = 2
                                          i_more    = 3 ).
    
    "If the line gets too long, I use double-indents to show continuation
    data(foo) = zcl_bar_factory=>get_instance->get_bar( 
        i_param   = 1 
        i_another = 2
        i_more    = 3 ).
    
    "And if it gets really long or for chained methods, wrap 'em all:
    data(foo) = zcl_bar_factory=>get_instance( )->get_bar(
        )->set_value( i_name = 'ID'       i_value = my_id
        )->set_value( i_name = 'CUSTOMER' i_value = customer_number
        )->set_value( i_name = 'AMOUNT'   i_value = order_amount    ).
     

    Note that I’m putting two parameters on the same line in the last example. Usually each parameter gets it’s own line, but here the tabular format of the entire name-value dataset is more sensible.

    All in all it’s content-driven. Consider simple SQL statements, just for fun here are two styles applied to the wrong type of statements:

     

     

    (8) 
    1. Jelena Perfiljeva

      This format makes sense to me. The last statement is easily readable as well as easily copy-pasted if someone needs to add another value.

      I’m glad to see at least someone understands the value of readability. Unfortunately, some of the 7.4 statements seem to be a “how much can I stuff into this one command” contests. It looks much better when formatted like in these examples. It’s like a well edited book. 🙂

      Nice blog, Jörg Krause !

       

      (2) 
      1. Mike Pokraka

        …and the reason my comment ended rather suddenly is because I posted by accident and couldn’t edit it. One of the many long-standing bugs on this “new” platform.

        I was going to write something along the lines of folks that cram a huge long SQL statement into one line vs others that write “vertical SQL” for even the simplest thing. I find this kind of thing painful:

        SELECT auart
          FROM vbak
          INTO lv_auart
          WHERE vbeln = lv_vbeln.   
        (0) 
        1. Bärbel Winkler

          Well, I’m actually in favor of writing selects like that regardless of how complex they are (or get).

          I do put more than one field into a line of the field list though – how many depends on the number of fields all told and how long the names are. This is how it might look:

            SELECT as4user   strkorr trkorr  trfunction trstatus
                   tarsystem as4date as4time langu
                   as4text   client  tarclient
              FROM e070ctv
              INTO CORRESPONDING FIELDS OF TABLE gt_e070ctv
             WHERE trkorr     IN s_cts
               AND as4user    IN s_user
               AND as4date    IN s_date
               AND trfunction IN s_trf
               AND trstatus   IN s_trst
               AND as4text    IN s_text.
          

          To me, having the same format for each select in a program improves readability and I find it more painful if each select has a different look and feel. 🙂

           

          (2) 
          1. Jörg Krause Post author

            I also tend to do “vertical” sql statements – just to be able to easily add things like fields or conditions afterwards.

            I see that you align the keywords in your select in order to align the following denominators. This may be an optical advantage, but to me it seems to be an obstacle in fluently typing in the code.

            My approach here is:

            select 
              matnr as material,
              spras as language,
              maktx as description
              from mara
                join makt 
                  on makt~matnr = mara~matnr
              for all entries in @lt_key
              where
                matnr = @lt_key-matnr and
                spras = @lt_key-spras
              into table @data(lt_mat_texts).

            note that I use the new SQL syntax here. Especially to have one line for each field of the field list makes it easier to add new fields afterwards. Apart of that, it lets you use the block select function of the editor to grab all fields, which comes handy if you later want to create an according type for the result.

            (0) 
          2. Mike Pokraka

            I think you’re missing my point. Your example is sensible and close to the way I’d  write it.

            We read from left to right, so this is the easiest to read if the logic is simple – e.g. my example of picking a single value from a table, or checking existence or counting. There’s no need to split this over three lines:

            SELECT SINGLE @abap_true FROM vbak WHERE vbeln = order_number.

            It’s perfectly understandable as is. Contrast with:

            SELECT SINGLE @abap_true 
                   FROM  vbak 
                   WHERE vbeln = order_number.

            Writing it as a list of clauses decreases readability in this case because we have to scan left to right and up and down. Typically I find myself reading the second version twice to make sure I understood it.

            So my original point is that it’s about balance. When the statements get more complex, then ease of comprehension is more important than ease of reading. Horizontal makes for more fluid reading, vertical provides more structure.

             

            (3) 
            1. Enno Wulff

              I understand both of you Bärbel Winkler and Mike Pokraka and I often switch between both variants. When is a statement short enough to put it in one line and when should I split it into several lines? It depends on many things – at least on the weather outside… 😉

              One word about “reading”: you mostly do not read everything. You fly over the code. Therefore the column based format is much better, because your eyes can catch the content easier. Even if the lines are not that long.

              Mostly I try to format the code by respecting best copy and paste and inserting and deleting conditions. That means: If there is something in the command or command flow that might become obsolete or if there must be inserted something: What is the best format w/o touching the adjacent lines?

              Therefore I mostly do not use colons like

              DATA: a TYPE i,
                    b TYPE d,
                    c TYPE n.

              Instead I always use:

              DATA a TYPE i.
              DATA b TYPE d.
              DATA C TYPE n.

              This makes it easy to decomment unused variables or cut variables when refactoring the function. It also makes it easier to group variables to blocks using CTRL-ALT-UP/ DOWN:

              The same with SELECT fields FROM or VALUE

              DATA(data) = VALUE my_table_type( 
                               ( one = '1' two = '2' )
                               ( one = '6' two = '4' ) 
                            ).

              Overall: Beautfying all the complex new 740+ commands is really a challenge… 🙂

              (1) 
          3. Bärbel Winkler

            Not sure, if I’m really missing your point, Mike! I guess it just comes down to slightly different points of view with my preference being a similar format for each select statement in a program. I’m actually quite happy that ABAP is flexible enough to not really insist on a specific way/sequence to write statements like this – otherwise it would just be one more thing to memorise and stick to (and there are more than enough of those already).

             

            (1) 
            1. Jelena Perfiljeva

              I agree. I write exactly like in your example above, although if it’s just one field I might write SELECT … INTO … and then the rest on the next lines.

              This seems more of a personal preference / style thing. I wouldn’t hold back a code review if I saw Mike’s version either. It’s just a habit for me to write on separate lines. Besides, simple statement today, complex tomorrow. 🙂

              When it comes to SELECT, the most irritating thing though is ABAP’s very strong preference in the placement of spaces and parenthesis. And if you do it wrong, you don’t get an intelligent error message like “hey, I think you forgot a space here” but something like “I have no idea what these fields are”. At least in 7.3, maybe this got improved in later versions.

              (0) 
        2. Joachim Rees

          Haha, I thought you had somehow implemented a screenshot from some 3rd-Party site, which was then blocked by my uMatrix-Opera AddOn – great to learn the explanaiton is much simpler!

          (0) 
  2. Bärbel Winkler

    Thanks for this blog post, Jörg!

    As a veritable newbie when it comes to ABAP OO, I very often have a hard time deciphering what long statements actually produce as a result. I even tend to “space out” much like I do when confronted with mathematical or scientific notations and formulas. So, something I really appreciate in addtion to thoughtful formatting is a clarifying comment preceeding such a statement.

    I’m also a fan of a strategically placed empty line preceeding and following (blocks of) statements.

    (0) 

Leave a Reply