Cleaning up my AdT report template (get rid of empty lines)

So CleanAbap is a thing, right and you have to start somewhere.
A very easy way for a quick win is getting rid of empty lines

Once I did that, it now relay pains me, when I see to much space in code.

That also happend, when I saw the code of my AdT-Report Template here: https://blogs.sap.com/2018/04/05/jump-start-your-report-writing-using-a-template-adt-eclipse/ .

I took it as a chance to clean it up.
As a first step, I only delete empty lines (I even resisted the temptation to delete comments or move a lonely “.” up one line. )

So her is how it looks now:

*REPORT  generic
Types: gty_data type ${my_table} ,
       gty_tab_data TYPE STANDARD TABLE OF gty_data .

*data, solely for select-options.
data: gso_${my_table} type ${my_table}.

*Sel-Screen:
SELECTION-SCREEN BEGIN OF BLOCK sel_opt WITH FRAME TITLE text-t01.
SELECT-Options: so_${my_table_field} for gso_${my_table}-${my_table_field}.
SELECTION-SCREEN END OF BLOCK sel_opt.
SELECTION-SCREEN BEGIN OF BLOCK mode WITH FRAME TITLE text-t02.

PARAMETERS: pa_disp TYPE flag RADIOBUTTON GROUP mode DEFAULT 'X',
            pa_proc TYPE flag RADIOBUTTON GROUP mode.

SELECTION-SCREEN END OF BLOCK mode.

CLASS lcl_report DEFINITION.
  PUBLIC SECTION.
    class-METHODS: init. 
    METHODS: 
                 get_data CHANGING ct_data TYPE gty_tab_data,
                 display_data CHANGING ct_data TYPE gty_tab_data,
                 process_data IMPORTING it_data TYPE gty_tab_data.
ENDCLASS.                    "lcl_report DEFINITION

CLASS lcl_report IMPLEMENTATION.
  METHOD process_data.
    FIELD-SYMBOLS: <data> LIKE LINE OF it_data.

    CHECK it_data IS NOT INITIAL.
    LOOP AT it_data ASSIGNING <data>.
*do something
    ENDLOOP.
  ENDMETHOD.                    "process_data

  METHOD display_data.

    DATA: lr_alv          TYPE REF TO cl_salv_table.
    DATA: lr_functions    TYPE REF TO cl_salv_functions_list,
          lr_layout       TYPE REF TO cl_salv_layout,
          ls_key          TYPE salv_s_layout_key.
    TRY.
        CALL METHOD cl_salv_table=>factory
          EXPORTING
            list_display = if_salv_c_bool_sap=>false
          IMPORTING
            r_salv_table = lr_alv
          CHANGING
            t_table      = ct_data.
        ##NO_HANDLER.
      CATCH cx_salv_msg .
    ENDTRY.

    lr_layout = lr_alv->get_layout( ).
    ls_key-report = sy-repid.
    lr_layout->set_key( ls_key ).
    lr_layout->set_default( abap_true ).
    lr_layout->set_save_restriction( if_salv_c_layout=>restrict_none ).
    lr_functions = lr_alv->get_functions( ).
    lr_functions->set_all( abap_true ).

    CALL METHOD lr_alv->display.
  ENDMETHOD.                    "display_data

  METHOD get_data.      
select * from ${my_table}  into CORRESPONDING FIELDS OF table ct_data UP TO 500 ROWS
  where ${my_table_field} in so_${my_table_field}
  .              
  ENDMETHOD.

method init.
  DATA: lt_data TYPE gty_tab_data,
        lo_report TYPE REF TO lcl_report.

  CREATE OBJECT lo_report.
	lo_report->get_data( CHANGING ct_data = lt_data ).
  check lt_data is not initial.

  CASE abap_true.
    WHEN pa_disp.
      lo_report->display_data( changing ct_data = lt_data ).
    WHEN pa_proc.
      lo_report->process_data( EXPORTING it_data = lt_data ).
  ENDCASE.
endmethod. 

ENDCLASS.                    "lcl_report IMPLEMENTATION

START-OF-SELECTION.
  lcl_report=>init( ).

Compare the code blocks in the two blog entries: better, isn’t it?

Deleting empty lines is easy and save(as in: it is really unlikely that you break stuff that way), yet the code benefits from it.

Do you do that, too? Do you see any drawbacks? I’d like to know!

best
Joachim

PS: I did some more cleaning, you can read about it here: https://blogs.sap.com/2020/06/18/cleaning-up-my-adt-report-template-part-2-more-cleanabap/