Python: Detect code which gets never executed in production

Question

I need to do refactoring in a big legacy Python code base.

Often I think "these lines don't get executed in production any more".

But I am unsure.

There are some tests which touch these lines. But I can't tell for sure if really no usage happens in production.

What can I do in this situation?

This question is about coverage on a production system. This question is not about coverage during testing/CI.

I don't want to comment out that lines, since I don't want to produce an error in the production system.

Departmentalism

Comment out that lines of code and see if your program works well. Do some tests and check the exceptions. – Aerostation

@CarloFedericoVescovo I don't want to comment out that lines, since I don't want to produce an error in the production system. I updated the question. – Departmentalism

Answer 1

Common practice is to use logging inside that lines of code. e.g. you have a block of code you think is not in use. You add try catch block in the beginning of that block of code. Inside trycatch you add line to a specific json named same as your suspicious block of code.

try:
    with open("block1.dat", "rb") as file:
        activity = pickle.load(file)

    curtime = datetime.datetime.now().strftime('%Y-%m-%d %H:%M:%S')
    currentact = "dt = {}; code done that: var1 = {}, 
        var2 = {}".format(curdate, var1, var2)

    activity.append(currentact)

    file = open("block1.dat", "ab")
    pickle.dump(activity, file)
    file.close()
except Exception: pass

You can use telegram api to log code to. After a while You'll get info how often your code works and what does it do. Then you monitor for a while and if nothing happens in a month, You can comment the block.

Procarp

Yes, you are right. Thank you. Logging can be used. But why pickle.load() and pickle.dump()? – Departmentalism

I just share my experience. In the code above I add line to a file each time the block of code executes. You can use telegram bot (I use) or slack channel notifications or sqlite if you prefer file storage but aware of file blocking. – Procarp

Answer 2

Is the production system deterministic? Is it interactive? Does control flow depend on input data? Do you have access to all possible inputs? Do the tests exist for a reason or just because?

I'd be careful removing code based on what is needed based on logging unless I knew there are no exceptional situations that occur rarely.

I would follow the common code paths to try to understand the codebase piece by piece in order to figure out what can be simplified. It's hard to give more specific advice without knowing more about the system you're dealing with.

Flanders

Deterministic: Yes. interactive: yes (web). Control flow depends on input: yes. Access to all possible inputs: yes. The tests exist we think they help us. You would be careful removing code based on logging. In my case I would trust this: "if this code was not used during the last 5 months, and not test touches it, then it can be removed". But this depends on the context. Maybe this is completely different in the context of my next project. I tried to understand the code path and my conclusion: this is dead code. But of course I am just a fallible human and could be wrong. – Departmentalism

Answer 3

We use a simple pattern to handle this: looks_like_dead_code(my_string)

This is a method which logs the string "my_string".

Example usage:

    if ext == '.jpe':
        looks_like_dead_code('2018-11-30 tguettler: looks fixed in mime_type_to_extension')

Using the date and the developer login is not enforced, it is just best practice.

If the line gets executed the one who is responsible for checking the logs will talk to the developer.

Since our production environments get updated roughly once in two weeks, you can be sure that this line was not executed during the last months.

I like this solution since in most cases it is like this:

1. you want to fix a bug or implement a new feature
2. you look at the code and see some lines which look like dead code. I mean code which is useless, since it won't get executed any more.
3. You don't have hours of time to investigate. You can dive into your vague guess that this is dead code. You want to do your actual work (fix a bug or implement a new feature. See Step1)
4. The method looks_like_dead_code() gives you a way to actually do something and leave a note for other developers. It only costs some seconds improve the current situation.
5. If you have a Tickler file System you can remind yourself to check this code in six months. At least in my context I can be very sure that this is dead code if this line was not executed for several months.

Departmentalism