Static ABAP code analysis can be a real asset. It depends on the specific checks being performed. Personally, I’ve had very good experiences with the standard versions of the ABAP Test Cockpit (ATC) in the past.
However, I’ve also seen custom ATC check rules and third-party code analysis tools that could really ruin your workday. It’s understandable that such ATC versions and third-party tools don’t have many fans.
Nevertheless, I wouldn’t go so far as to try and circumvent static code analysis. But that’s exactly what I saw recently in a code review. A rather lonely decision by an ABAP developer. Especially since there was no professional justification and one was almost forced to assume that it fell into the category of “not wanting to do it properly”.
I’m sure there’s a better way. If you’re not happy with the result of a code analysis, here are a few suggestions on how to deal with it.
Let’s start with the suggestions if the check result is correct and therefore a code adjustment is necessary:
- If a suggested correction is provided, apply it if appropriate.
- Change the design of the affected code section. The goal here is to make it technically sound, not to try and trick the code check with a lot of imagination.
Here are the suggestions if the check result is incorrect and therefore no code adjustment is necessary:
- Inform the code analysis tool via Pseudo Comment or Pragma that it should no longer flag the code for that specific section.
- Change the check rule. This may sometimes require collaboration with people from other departments. However, the effort is worthwhile because all developers will benefit.
- Modify the design of the code in question so that the code analysis tool can better assess it and consequently approve it.
These are just a few suggestions, quickly jotted down. Perhaps someone else has another suggestion?
Thank you for reading. If you enjoyed the post, please share the article with your community. Thanks in advance.
Michael (a mind forever voyaging)