-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include from 2015 is being checked and throwing errors #556
Comments
This is not a bug: The object creation date configuration refers to the creation date of the checked main object, i.e. in this case the creation date of In general, using the creation dates for individual includes rather than the creation date of the main program would lead to very confusing situations: If a global class is created before the threshold, but a new method is then created after the threshold, then we would get findings only for this method. In contrast, new methods in a local class wouldn't trigger findings because local classes don't have individual includes for each method on a technical level. Hence, only the creation date of the main object is relevant in order to avoid confusing situation. In general, newly created objects shouldn't reuse old code via |
Recently our team started a refactor in report INCLUDE harcimpu_f01.
INCLUDE harcimpu_f02.
INCLUDE harcimpu_f03.
INCLUDE harcimpu_f04.
INCLUDE harcimpu_f05.
INCLUDE harcimpu_f06.
INCLUDE harcimpu_f07.
INCLUDE harcimpu_f08.
INCLUDE harcimpu_f09.
INCLUDE harcimpu_f10. As the code from these includes is a cut and paste from the content of -- This example goes agaisn't your words, or perhaps I missuderstood it. Can you please check? If you need a real example, I can check with my team to remove some of the pragmas so that you can check the errors. Thanks! |
Ah, this is an issue with "includes" in ABAP being treated inconsistently. The correct statement is that the creation date of the smallest TADIR object enclosing the line in which a finding is found is relevant. For a finding in e.g. a class, this will always be the entire class, even if the individual methods exist as includes on a technical level. But includes that are included via It is unclear to me whether this is intentional or not, but at least this merits discussion - reopening. |
so I don't really understand...
In both scenarios, the includes are added with the literal statement Can you help me clarify? |
Yeah, the first one shouldn't happen according to my current understanding of the code - which means either there's a subtle bug somewhere or I haven't actually understood what's going on ;) (but also: you really shouldn't be producing situations like the first one - multiply-used includes are a much bigger code smell than anything the code pal checks might find inside that include...) |
Unfortunately we don't have much power over that entire report, as it is automatically generated by the system. Down sides of working with such legacy systems. |
Check Name
Error replication
Actual Behavior
This is unexpected because the only includes subject to analysis should be those with creation date >= 2018.
Expected Behavior
The text was updated successfully, but these errors were encountered: