Deleting code matters

Developers jobs are often defined as “writing code”. I’d argue than being able to remove unnecessary code is a much more critical skill.

Why you should delete code

Long story short, the real cost of engineering is not writing code. The bulk of the time is spent by developers on reading and editing code. This is because making a change in an application (design and / or functionality) requires to understand the current code to find the right spot(s) to update. Even before making a change, the code must be understood to estimate how much work a change would take. Developers also have to fix bugs where the intent of the code and what it actually does must be understood. In all cases, the less code there is to read the better.

Obviously, let’s not mess with the code-readability

I’m not suggesting here to delete characters; or to avoid new functions to make the code a bit shorter. This article is about removing code that is not (anymore) necessary. To reiterate, less code does not mean less line of codes and/or less characters, it means less logic to read and to understand.

The things to delete

Commented-out code

Keeping commented-out code around in case is completely unnecessary. Yes, you’ve spent some time writing something which might eventually be useful but that doesn’t mean it should stay around and trash your files. Just remove it and commit it (you can always retrieve it later).

unused import statements

Your IDE probably outlines unused import statements for you. Remove these.

Code which is not used anymore

You wrote an import scripts and the import has been done in production several weeks ago. It was a complicated one; it took time and effort. It was fully unit-tested. Just remove it along with all related tests and documentations. Again, do this in one commit, you can retrieve it later. By removing it, you avoid other developers to find it when searching for something else.

Comments that aren’t that helpful

Often a comment just explains what the code does without providing any extra information. That’s a learner type of comment and there is no need to keep it around. For example, you can replace:

def calculate_price(item, quantity, currency=USD):
    """" 
    Currency is in USD by default.
    Other supported options are: EUR, AUD and CAD.
    NZD support TODO. 
    """"
    ...

with:

def calculate_price(item, quantity, currency=USD):
    """"
    Other supported currencies are: EUR, AUD and CAD.
    NZD support TODO. 
    """"
    ...

Another type of comment that can be removed are comments that can be replaced with actual code. We can edit further that example and replace the comment about the supported currencies with an assert:

def calculate_price(item, quantity, currency=USD):
    assert currency in [USD, EUR, AUD, CAD]  # NZD handling TODO
    ....

In this case, replacing the comments with code is not only easier to read; it will also potentially avoid issues during development. Read more tips about commenting your code here.

Code that achieves nothing

That might sound surprising but code doing nothing at all is more common than we would like it to be. Here are two examples:

1.Parameters in dictionary that aren’t used anymore

In MVC frameworks, the controller handles the data to the view (i.e. the template). The unused data is usually not highlighted by our IDEs so it’s quite common for developers and designers to leave unused things there when updating templates. The problem is that you might end-up with very long listing of items. If you are passing more than a couple of items to a template (i.e. the current page, the current user and a form for example), I would strongly suggest to group together some these items and/or to track down the unused one to keep things clean.

2.Code that cannot be reached

Unreachable code is simple as:

def my_function(...):
    if condition_a or condition_b:
        do_something()
         return something

     if not condition_b:
          # unreachable code
          do_something_else()

      return ....

This might be a situation where the code should be fixed, not deleted.

Test it all and delete as much as you can

Overall, any code that can be removed without having the tests failing should be ultimately removed.

If you are lucky enough to work on a TDD application, you can simply rely on the test suite to make sure nothing is breaking. I think one of the biggest reason for developers to not remove code - even if they think it should be removed - is the fear of breaking something. The only sane way to not be scared of breaking something is to have good code coverage and to regularly refactor your code.

September 2023