styleguides
styleguides copied to clipboard
SAP
structure of interface or class definitions
Hi, In CLASS or INTERFACE definitions, the DATA/METHOD definitions can be interleaved, personally I don't expect any TYPE/DATA/CONSTANTS etc definitions after METHODS definitions, but what is considered good practice?
I don't have an opinion regarding DATA/TYPE /CONSTANTS ordering, just that METHODS are last in the section.
Bad example(?), I don't personally expect to see DATA or TYPES after METHODS are defined,
CLASS lcl_foo DEFINITION.
PUBLIC SECTION.
DATA hello TYPE i.
METHODS foo.
DATA bar TYPE i.
TYPES moo TYPE i.
METHODS boo.
ENDCLASS.
Good example(?), methods are defined last in the section,
CLASS lcl_foo DEFINITION.
PUBLIC SECTION.
DATA hello TYPE i.
DATA bar TYPE i.
TYPES moo TYPE i.
METHODS foo.
METHODS boo.
ENDCLASS.
I always do this order.
Types Constants Interfaces Class Events Events Class methods Methods Class data Data
Intention being you scroll up to get the referenced type. Not sure why I do data below methods. I don't expect to find methods after data :P
heh 😄
As a consequence of having DATA after METHODS its not possible to do LIKE typing. Below code has a lot of other problems, and might be a bad example altogether
CLASS lcl_foo DEFINITION.
PUBLIC SECTION.
DATA bar TYPE i READ-ONLY.
METHODS set_bar IMPORTING bar LIKE bar.
ENDCLASS.
I totally agree with @larshp. TYPE/DATA/CONSTANTS shouln't be randomly placed in the definition of a class.
Declarations first. Always.
It's not just because I'm an old dinosaur who grew up with legacy code, but there are technical constraints. Lars already mentioned LIKE (should we be using that?). But another logical reasoning is that we need TYPES up front to use them as method parameters. It makes sense to keep associated DATA near the TYPE. Therefore we need to have them before METHODS because having DATA afterwards splits them up.
CLASS lcl_foo DEFINITION.
PUBLIC SECTION.
TYPES t_thingies TYPE STANDARD TABLE OF some_structure.
DATA thingies type t_thingies.
METHODS constructor IMPORTING thingies type t_thingies.
METHODS...
Putting this kind of DATA at the end of a list of METHODS far away from its TYPE is just horrible.
But then I was most surprised to read the Clean ABAP book does DATA after METHODS...
@pokrakam, you were questioning the use of LIKE. Well, LIKE used with TABLE-FIELD is obsolete. But LIKE used with another variable makes a lot of sense.
Example 1 (you only mention KNA1 once instead of twice): DATA customer TYPE kna1. DATA t_customer LIKE LINE OF customer.
Example 2 (a local variable is declared LIKE an input parameter): DATA aux LIKE i_param1.
Both examples make the code easier to maintain and thus safer.
@larshp Not directly, I just noticed the sample code was written that way. It struck me as odd straight away. Great book BTW.
Fully agree with @larshp & @pokrakam
TYPES, DATA,.. should stay before the methods. I also never have seen something different in any customer system before.
@nununo when I made that comment I was actually thinking about the usage LIKE table-field. I agree with the idea behind your examples, but in practice I haven't used LIKE in a very long time. I'm far more likely to use inline declarations instead.
LOOP AT customers INTO DATA(customer).
DATA(aux) = i_param1.
A use case for example 2 could be a function module call, but there again the DATA declaration is usually made with quick fixes and should match the FM rather than an importing parameter.
Declarations first. Always.
It's not just because I'm an old dinosaur who grew up with legacy code, but there are technical constraints. Lars already mentioned LIKE (should we be using that?). But another logical reasoning is that we need TYPES up front to use them as method parameters. It makes sense to keep associated DATA near the TYPE. Therefore we need to have them before METHODS because having DATA afterwards splits them up.
CLASS lcl_foo DEFINITION. PUBLIC SECTION. TYPES t_thingies TYPE STANDARD TABLE OF some_structure. DATA thingies type t_thingies. METHODS constructor IMPORTING thingies type t_thingies. METHODS...Putting this kind of DATA at the end of a list of METHODS far away from its TYPE is just horrible.
But then I was most surprised to read the Clean ABAP book does DATA after METHODS...
Usually your thingies should be private....
its not really the topic of this issue, just change it to private
CLASS lcl_foo DEFINITION.
PRIVATE SECTION.
TYPES t_thingies TYPE STANDARD TABLE OF some_structure.
DATA thingies type t_thingies.
METHODS constructor IMPORTING thingies type t_thingies.
METHODS...
The more realistic scenario would probably be that some members would be split between public and private, so that would break the flow you're trying to impose.
First and foremost, I consider the prime directive to be "group all declarations and definitions".
Given the technical limitations you might end up with one type before the others.
I usually put TYPES before METHODS before DATA.
Admittedly I rarely use LIKE because I always do ADT-quickfix-supported refactoring so the benefit of indirect types through LIKE is diminished and because the where-used list does not play very nice with it.
But: With a proper separation of concerns you should end up with small-ish classes whose definition sections (e.g. the PUBLIC SECTION) fit on one or two vertical screens anyway. At that point it should become clear that the order is rather unimportant and mostly a matter of taste.
