Folks,
One does not need a sixth sense to see the dead ABAP code. Like love in the popular song, it’s “all around me and so the feeling grows”. The feeling of intense dislike that is.
In most cases, dead code used to be alive. It was part of the program and possibly served a business requirement until it became unnecessary and was commented out. Which is the ABAP equivalent of “sent to the farm upstate”.
Some of the dead code was never alive. This includes the “version control” comments, the “keep just in case” prototypes, etc.
Dead code creates clutter and does not "spark joy”. It was one of the points in my 2018 TechEd presentation, illustrated by the following slide.
The picture on the right is a made-up code example but the picture on the left is a real-life image from one of the rooms in my house. My husband is a bona fide hoarder, and this is just a part of his prized possessions. I do love him regardless of this addiction and therefore have to compromise by sacrificing some space for storing this junk (definition we still disagree on). But in the professional SAP world, we should not need such compromises and the candy… err… code with 2009 expiration date can be simply tossed.
Dead code makes debugging more difficult as well. Just recently I had to debug a function module where ELSE statement was separated from the IF statement by hundreds of lines of commented out code. Not the most pleasant experience.
Search in the programs is also affected negatively by the dead code. This is especially true in the legacy programs with a massive number of INCLUDEs and global variables.
Finally, dead code can lead to the confusing statements in the comments. For example, when a comment says “the code below is very important because such-and-such” and then is followed by a chunk of dead code, it’s impossible to tell whether “below” refers to the dead code (and therefore the comment is obsolete) or the comment applies to the active code further down.
There are 3 most common scenarios where the developers tend to claim the dead code is necessary. I call these “The Dead Code Myths”.
All ABAPers must have seen this: a trivial change gets surrounded by “begin of” / “end of” comments or a command is annotated with some identifier, such as a ticket number. All, presumably, in the effort to keep track of the program changes.
Just over 2 years ago, I was joining a team of several developers after working as a solo developer. Since each team has their own rules, either written or not, I was eager to learn the ways of the new tribe. As I was told, one rule was of utter importance: every program line, either changed or added must be annotated using a “tracking number”. It seemed excessive and the following dialog occurred between me and an incumbent team member.
— Why do you want me to do this?
— So that we can see what changes were made and do the code review.
— But if I make a change and do not mark it in any way, how would anyone know?
— Err… We could look in the version history.
— So, then why don’t we simply use version history to keep track of changes?
— Um… It’s not always clear.
— Why? There you go, it shows what was changed or added. We can compare two versions to see the difference.
— Well, that’s how we’ve been doing it for 20 years and that’s it!
Program comments must not be used as a version control method. It’s unreliable, annoying, and makes no sense. If the standard SAP version control is not sufficient for your team’s purposes, then use abapGit. It’s free.
Aka “But we need the old code to explain to the business users how the program worked before and how it was changed!”
The ABAP program is not a clay tablet documenting the chronicles of the business requirement evolution for the future generations. It is also not an antiques store. The ABAP program should only contain current, working (ideally, clean) code that executes the valid/active business logic.
Keeping track of the business rules and where they came from should be the realm of the business process owners and functional consultants. And they need to have some information management tools at their disposal.
Some dead code was never alive and possibly not completely dead. This could be the code that a developer finds potentially useful. For example, you spend hours trying to figure out how exactly to fill in all those structures for a BAPI call and even though half of them are not needed right now, you want to preserve this knowledge for future use. Technically, the BAPI parameters must be either self-explanatory or properly documented. But jokes aside, the working code is not the right place for the code examples. Program documentation or an offline repository is a more suitable solution in such case.
I am happy to report that after introducing new development guidelines that called for the dead code removal 2 years ago, no issues have been encountered so far in the team. The code is more clean, healthy, and conducive to further improvements. Significant maintenance effort reduction has been noted when working on the programs that have undergone the clean-up.
Program is a living organism and dead code is as useful as a gangrene. Let it rest in peace in the version control.
One does not need a sixth sense to see the dead ABAP code. Like love in the popular song, it’s “all around me and so the feeling grows”. The feeling of intense dislike that is.
What is “dead code”?
In most cases, dead code used to be alive. It was part of the program and possibly served a business requirement until it became unnecessary and was commented out. Which is the ABAP equivalent of “sent to the farm upstate”.
Some of the dead code was never alive. This includes the “version control” comments, the “keep just in case” prototypes, etc.
Why is it bad?
Dead code creates clutter and does not "spark joy”. It was one of the points in my 2018 TechEd presentation, illustrated by the following slide.
The picture on the right is a made-up code example but the picture on the left is a real-life image from one of the rooms in my house. My husband is a bona fide hoarder, and this is just a part of his prized possessions. I do love him regardless of this addiction and therefore have to compromise by sacrificing some space for storing this junk (definition we still disagree on). But in the professional SAP world, we should not need such compromises and the candy… err… code with 2009 expiration date can be simply tossed.
Dead code makes debugging more difficult as well. Just recently I had to debug a function module where ELSE statement was separated from the IF statement by hundreds of lines of commented out code. Not the most pleasant experience.
Search in the programs is also affected negatively by the dead code. This is especially true in the legacy programs with a massive number of INCLUDEs and global variables.
Finally, dead code can lead to the confusing statements in the comments. For example, when a comment says “the code below is very important because such-and-such” and then is followed by a chunk of dead code, it’s impossible to tell whether “below” refers to the dead code (and therefore the comment is obsolete) or the comment applies to the active code further down.
Guide to Debunking The Dead Code Myths
There are 3 most common scenarios where the developers tend to claim the dead code is necessary. I call these “The Dead Code Myths”.
Dead Code as Version Control
All ABAPers must have seen this: a trivial change gets surrounded by “begin of” / “end of” comments or a command is annotated with some identifier, such as a ticket number. All, presumably, in the effort to keep track of the program changes.
Just over 2 years ago, I was joining a team of several developers after working as a solo developer. Since each team has their own rules, either written or not, I was eager to learn the ways of the new tribe. As I was told, one rule was of utter importance: every program line, either changed or added must be annotated using a “tracking number”. It seemed excessive and the following dialog occurred between me and an incumbent team member.
— Why do you want me to do this?
— So that we can see what changes were made and do the code review.
— But if I make a change and do not mark it in any way, how would anyone know?
— Err… We could look in the version history.
— So, then why don’t we simply use version history to keep track of changes?
— Um… It’s not always clear.
— Why? There you go, it shows what was changed or added. We can compare two versions to see the difference.
— Well, that’s how we’ve been doing it for 20 years and that’s it!
Program comments must not be used as a version control method. It’s unreliable, annoying, and makes no sense. If the standard SAP version control is not sufficient for your team’s purposes, then use abapGit. It’s free.
The Dead Code Chronicles
Aka “But we need the old code to explain to the business users how the program worked before and how it was changed!”
The ABAP program is not a clay tablet documenting the chronicles of the business requirement evolution for the future generations. It is also not an antiques store. The ABAP program should only contain current, working (ideally, clean) code that executes the valid/active business logic.
Keeping track of the business rules and where they came from should be the realm of the business process owners and functional consultants. And they need to have some information management tools at their disposal.
Potential Zombie
Some dead code was never alive and possibly not completely dead. This could be the code that a developer finds potentially useful. For example, you spend hours trying to figure out how exactly to fill in all those structures for a BAPI call and even though half of them are not needed right now, you want to preserve this knowledge for future use. Technically, the BAPI parameters must be either self-explanatory or properly documented. But jokes aside, the working code is not the right place for the code examples. Program documentation or an offline repository is a more suitable solution in such case.
Conclusion
I am happy to report that after introducing new development guidelines that called for the dead code removal 2 years ago, no issues have been encountered so far in the team. The code is more clean, healthy, and conducive to further improvements. Significant maintenance effort reduction has been noted when working on the programs that have undergone the clean-up.
Program is a living organism and dead code is as useful as a gangrene. Let it rest in peace in the version control.
- SAP Managed Tags:
23 Comments
| User | Count |
|---|---|
| 5 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
