Align METHODS declarations unaligns method declarations

[sap]

Align METHODS declarations unaligns method declarations

[jmgrassau]

Hi Fabian,

not sure what you mean with "unaligns method declarations" here: As far as I can see, the main difference between "Before" and "After" is that empty lines were introduced. This is done intentionally (to improve readability) by the following option in the "Align METHODS declarations" rule (and this one already works on interfaces, too :-)

If you prefer the "Before" state, you could of course deactivate this option. So, unless I misunderstood your point, I think this issue can be closed, otherwise please let me know, then we can reopen it!

Kind regards,
Jörg-Michael

[fabianlupa]

Sorry I could have simplified the example a bit. I am talking about this part:

Before

  METHODS:
    get_supported_methods RETURNING VALUE(result) TYPE zabc_fs_method_enum=>instances,
    get_description RETURNING VALUE(result) TYPE string,
    file_exists IMPORTING path          TYPE csequence
                RETURNING VALUE(result) TYPE abap_bool
                RAISING   zabc_fs_unsupp_operation
                          zabc_file_system_exception,

After

 METHODS: get_supported_methods RETURNING VALUE(result) TYPE zabc_fs_method_enum=>instances,
          get_description       RETURNING VALUE(result) TYPE string,

    file_exists IMPORTING !path         TYPE csequence
                RETURNING VALUE(result) TYPE abap_bool
                RAISING   zabc_fs_unsupp_operation
                          zabc_file_system_exception,

Before all method definitions were at the same indentation level, after the first two are separated. Though I have no use for any changes as this will not apply anymore to me after #12.

[jmgrassau]

Hi Fabian,

ah, now I see! Hm, yes, this seems to be a bit of a conflict between ABAP cleaner trying to create one-liners, and on the other hand breaking after METHODS: Will have to look into this!

Kind regards,
Jörg-Michael

[jmgrassau]

Hi Fabian,

with the above commit, this should be fixed in the next release (version 1.2)!

Kind regards,
Jörg-Michael

[fabianlupa]

By the way: Love the responsiveness to the issues! I would recommend to pick a different approach to closing them though. Having the fixes on a main branch in a fork that is presumeably merged some time in the future discourages people from contributing as the code base in the base repo is outdated and you cannot see pending changes directly either.