• 05 December 2025

I’ve just been doing some prefactoring and I ran into an interesting situation with some dead code.

What’s prefactoring?

Prefactoring is refactoring in preparation for a piece of development work.

There are several situations in which prefactoring is useful.

Improving understanding

Sometimes code you are about to work on is unclear or difficult to understand. If you can see significant improvements, by way of refactoring, which make the code easier to understand, it’s a good idea to put these in place.

Simplifying implementation

Other times the code is just too difficult to make the necessary changes. In this case, it is sometimes possible to massage the code to get it into a better shape.

A bug?

While prefactoring, I came across a line of code which looked like it contained a bug. I didn’t want to get distracted, so I added a comment.

fn disconnect(&self) -> Result<(), MultiplexError> {
Ok(self
.ipc_sender
// FIXME: is ORIGIN always correct below?
.send(MultiMessage::Disconnect(self.sub_channel_id, ORIGIN))?)
}

After I’d finished my current round of prefactoring, I decided to explore the bug.

Write a failing test?

I thought of a test which should fail and went to implement the test.

I noticed a similar test – that was already passing – but assumed that test wasn’t provoking the bug. So I went ahead and wrote the new, somewhat more complex test.

The new test passed as well!

What was going on?

I’m used to the stages of understanding a bug, including “How could the code fail like that?” and “How could the code ever work in the first place?”, so I pressed on and ran the test with logging turned on.

Trawling through the logs, I couldn’t see where an incorrect Disconnect message was being sent. I even added a couple of logs to the testcase to pinpoint the problem: still no progress. I added logging to another function to give me more insight.

But it seemed like Disconnect messages were consistently being sent with the correct second parameter (i.e. not ORIGIN).

What was going on?

Dead code

Finally, I looked again at the context of the supposedly buggy line of code:

#[allow(dead_code)]
fn disconnect(&self) -> Result<(), MultiplexError> {
Ok(self
.ipc_sender
// FIXME: is ORIGIN always correct below?
.send(MultiMessage::Disconnect(self.sub_channel_id, ORIGIN))?)
}

Huh! I didn’t remember adding that allow attribute (to suppress a compiler warning about dead code) on the function. But, looking at the file history, I added it in a commit entitled “Tidy up” six months ago.

I clearly intended this code to become live at some point in the future, but hadn’t remembered to delete it when it was no longer needed. If this wasn’t a solo project, a colleague would probably have noticed the problem. But, for some reason, I was blind to the allow attribute.

I deleted the dead code (!), reverted the new test, and decided to write up my findings here, partly as penance and partly to entertain (and possibly inform) others.

Conclusion

It would have been far better not to suppress the dead code compiler warning, so there would have been a permanent reminder of the need to make use of the code or delete it.

• ← Previous IPC channel multiplexer