Skip to Content
Personal Insights

I See Dead Code

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.

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”.

  1. 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.

  1. 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.

  1. 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.

/
22 Comments
You must be Logged on to comment or reply to a post.
  • Hi Jelena – First of all, thanks to bring up this topic..and what a way to explain the pain?!! Can totally relate…The way your husband hoards, in a similar manner I see my wife’s clothes hoarded in my wardrobe..haha…Jokes apart:

    Dead code is gangrene, but I would shamelessly agree to your incumbent team member that seeing the code changes in the version control is cumbersome ( or let’s just say I am too lazy to stare at the screen and spot the minute difference ), and finding the changes in the dead code is far easier…

    Also, comparing the code version between multiple different versions one by one is tedious than just finding the code line insert in version 1 and version N via the “find and search” technique in one view of editor.

    Not just dead code, we see unnecessary live code as well, for example : clearing the local variables at the end of routine…and when questioned about it, we get the same answer — “We have been doing it from past 20 years”..Really??!!!

    IMHO, one way to tackle the problem of hundreds of lines of code, is to adopt modularization. It should be adopted to its idealistic definition ( one task in one module ). And yes, ATC setup in place to detect that there are no more than “N” number of lines in one module….May be this could be one approach to make our eyes see less dead code, until we move to AbapGit…

     

  • Hi Jelena – this reminds me of my previous job, where we did formal code reviews, and removed/ensured we removed dead code.

    Love this blog; I am sorry I missed your presentation too…perhaps one day, I’ll get to see it.

  • When I was young I lived with four other guys. One had a set of weights. The only time they ever got lifted was when we moved form one house to another.

    Our custom code is also littered with references to HEAT which was the Deloitte Consulting help-desk system in 1999, which we internal people had no access to back then, and obviously do not know, even if such a thing still exists.

    I am very happy to see the recent open source ATC checks (available via abapGit) which flag commented code as a hard error.

    AND YET

    There was a blog the other day from SAP itself saying lots of customers had asked for an automated tool to comment out old code and add the transport number as a comment when doing “Quick Fixes” to adapt code for S/4HANA. I understand that SAP has to do what the paying customers ask for, but in this case the paying customers are barking at the moon, foaming at the mouth, free energy crazy.

      • Don’t we all wish SapScripts were dead and stomped to the ground?   But since they work and do their job for the customer, we really can’t change them to PDF until they break.   AND THEN…

        It depends on if it is a quick fix

        If we have the luxury of time

        Then we can kill the darn things.

        I wish I had the laughing face for this one.

  • Thanks for your thoughts and comments regarding dead code, Jelena!

    I agree, that chunks of commented out code should be tossed sooner rather than later. I however disagree with only relying on version control to see what was changed and when. For that purpose, I find properly placed comments relating to the change(s) helpful as these are available in all systems and not just in development. They can therefore help a lot with troubleshooting an issue in production quickly where you don’t have versions for the code.

    Cheers

    Bärbel

    • I largely agree with Jelena, but I also agree with Bärbel – at least for one of my projects.

      We release new features and functionality to a suite of programs once a year. I do comment with the change number and the year. In this way, if something stops working, we use version management to see what changed – but we can also quickly find the change number and find out what the intent was. It’s very useful.

      Since the person fixing the issue might not be the programmer, it really does have utility.

      However, when I’m working on 2020 code, I’ll remove comments to any code from 2018 or earlier.

      • If there is a summary of changes/change log at the beginning of the program then the intent is there. The intent does not need to be mentioned in every changed line in the code, I think. Or if ABAP Git is used, then the intent is explanation in the commit. So here again no need for “begin/end comment” and leaving dead code.

  • Dead code – the bane of our existance.   That huge comment code, as soon as we delete it – it kills our versioning.  Yuck.   But it is well worth it.

    One thing in your blog I have a hard time with.   It’s the idea that we don’t have several re-writes.   Here’s what I mean – pretend you are going live with the dead code (just comments, but it could be in the program too)

    1. Design specification is constantly changing.  You have – because you don’t want to comment – changed the program.
    2. You’ve made several changes.   Nothing has moved to quality.
    3. So now the design changes back to the original.  However, you’ve also made several new changes.  You can’t easily remember what the code was like before.  If you’ve saved a version, it doesn’t matter.  You want to keep some of the changes.
    4. More changes.  Design goes back again.  Ah…  It’s going back and fourth.’
    5. Modularization helps a lot, but it doesn’t always work well.  Your back and fourth can be in the same object/method – along with those changes you want to keep.

    Now for me, it’s easier to comment so I can revert back and fourth without an issue.  When I’m particular “smart”  I just create another class that I go back and fourth with.   However that is creating a weird extra class that is never used.   Because yes, I can get rid of it.  Then it is tested and they want to move back to the old version of a piece of the code after testing in quality.

    Crazy right??

    So I might put in an “if statement”  where only one part of the code is used.  I might even leave it until the project goes live.   So then I want another transport to move in the corrected version getting rid of the dead code I created.   HA!   That doesn’t happen.  They don’t want to move anything unless it is for a project or break/fix.

    SO then prior to moving everything, I comment why on Earth I did it that way.   Sometime in the future in theory, I can fix my code.

    Now you run into the dead code program.  And it’s a mess I created.

    So in general, I totally agree with you.   Also in principle I hate doing what I described.   Obviously the design phase wasn’t completed prior to development.  Or it was, and the customer that you are working with doesn’t really know what they want until the code runs.

    So, yes I still do it.  When I can, I remove it.  I really remove it when it is something I developed.  Usually I comment the heck out if it, so I know why I did what I did.

    Sigh, I am part of the problem.

    • Dear Michelle,

      Nobody could argue against the fact that the specifications keep changing. Of course they do. It’s like the Hokey Kokey (Hokey Pokey in the USA) – in, out, in, out, shake it all about.

      So – let us say the business logic is going to change ten times, which is really common.It could even be the logic switching backwards and forwards between two different algorithms.

      The easiest thing to do is to keep both sets of logic and just comment out whichever one is out of favour that week.Then when it changes back the next week uncomment the dead code, comment out the other block. Then repeat the process the other way the next week when things change again.

      To keep using the party analogy this is like “pass the parcel” – when the music stops the code goes into production and then you have dead code which NEVER goes away (until I find it).

       

       

    • Just a tip. Eclipse keeps local versions of your code – then at least when you’ve made a change today that’s totally borked, you can revert to yesterday!

  • Hi Jelena,

    Excellent stuff as always from you. I couldn’t agree more that keeping all those commented out lines of code is as crazy as stuffing every room in your house with 50 years of clipped nails and cut hair.

    Most of all, it damages the readability of the code and restricts developers who want to make changes to a program. I’m glad you had some influence and were able to change the development process in at least one team.

    Best,

    Thorsten

  • Hello Jelena,

     

    The first thing I do when I start a new project is delete all the old commented out lines of code from the relevant objects.  It makes me so happy.

  • I have took one longer program (2000 lines)  from one SAP project. This program contains lot of changes marked with Begin.. /End… and smaller changes not marked  with Begin.. /End…(indenting change, adding few spaces, adding short inline comments). Then  I used SAP version control (VCS) and Git VCS (I pushed the old version of the program to Git, made commit, then I pushed new version and done second commit). These versions I downloaded from SAP first, as txt.  I was analyzing how these program changes will look in SAP VCS versus Git VCS. I was kindly surprised that GIT VCS better showed the changes, I understood these changes better comparing looking in these changes in SAP VCS.

    After this analysis I realized few things:

    1. Next time , if I will need to do code review for such complicated program updates I will use Git VCS
    2.  I could see that developers (I have noticed this in the past ) do not mark all changes with Begin.. /End… since they think they are too small and they do not want to spend time with adding a lot of change comments in the code.
    3. I understood these changes much better from Git VCS comparing when I observed changes directly in SAP looking Begin.. /End… comments. These comments did not help me better to understand changes…Git highlight these changes much nicer. And I could see all changes, not only those which were marked by developer. As a responsible code reviewer I need to see all changes.
    4. Now, there customers who would like to have these change comments in the code. If I would be a customer who received such code with these change comments and I would open also either SAP VCS or Git VCS then I would see these missing changes, not marked and I would ask myself– why developer did not mark all changes? How I can believe the changes marked by this developer if I see in VCS that he made much more changes? This feeling decrease the trust of customer to change comments. As a customer, I would then prefer not to have these change comments at all since they just clutter the live code I want to see.
    5. Git can be used very well by SAP developers even if they still did not start with ABAP Git. They can at various point of time during coding push there few programs they are currently working on to Git and using commits they can go back to these commits and get back their code for that time. This will solve problems mentioned above in this blog where requirements are changing and developers need to go back to previous versions which are not visible in SAP VCS.  Also  they start to better understand Git and they will be better prepared to ABAP Git.
    6. I do not see a good practice if during code update of some older program developer creates changes in the lines of code he does not need to change….I mean these very small changes where a space is added or some inline comment for some older code…these changes are uselessly cluttering VCS comparing tools and their value added is mostly negligible, they do more harm.
  • There are also some other topics around dead code, that people might be interested in reading:

     

     

    • Thank you for the comment, Sandra! It’s interesting that SAP’s definition of “dead code” is slightly different. It looks like they mean the code that is active, i.e. not commented out, but is simply not executed. I was talking more along the same lines as Clean ABAP mentions and mostly meant the commented out code. Both qualify as “dead code”, in a sense.