Reusable code vs. re-editable code

In a recent interview, Donald Knuth made this comment about reusable code. I also must confess to a strong bias against the fashion for reusable code.

I also must confess to a strong bias against the fashion for reusable code. To me, “re-editable code” is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.

Knuth didn’t elaborate on what he means by “re-editable” code, but I assume he means code that is easy to maintain. The best chance most code has at reuse is remaining useful in its original project over multiple versions, so maybe we’d get more reuse if we focused more on maintainability.

I think whether code should be editable or in “an untouchable black box” depends on the number of developers involved, as well as their talent and motivation. Knuth is a highly motivated genius working in isolation. Most software is developed by large teams of programmers with varying degrees of motivation and talent. I think the further you move away from Knuth along these three axes the more important black boxes become.

3 thoughts on “Reusable code vs. re-editable code

  1. I can see both sides of this coin, and offer a more personal take on the subject: re-usable code is code that *I* can re-edit!

    The art of developing interfaces to libraries to promote “black box” re-usability of code is something not covered (to my knowledge) in TAOCP, nor should it be.

  2. “Good code is easy to change.
    All code will change until it is no longer easy to change.
    All code becomes bad code.”


    Basic lessons in entropy, applied to programming…

  3. On the other hand, standard library code is reusable code, not re-editable code. But it’s so good that it’s ok to reuse it even if you don’t edit it. Reusing printf is fine.

Comments are closed.