Many projects need a set of various utilities. There is some discussion about where to place them. But what happens if the utility becomes part of the standard?

For example, C++ kept adding to the standard many useful functions. For example, std::clamp, or the random number generators. Many projects needed that functionality, and was relying on a different library or wrote those functions themselves.

Is it worth the effort to try and move towards the standard?

This might reduce the number of dependencies, simplify and standardize the codebase. And might be easy to do in some cases (such as the simple std::clamp example). But might be at the same time a large change, which might lead to conflicts, time lost debugging some issues, finding ways to mitigate the differences, and so on.

The same question also applies if some functionality, previously handwritten, gets added to a library (e.g. boost), which is also used in the project.

2 Answers 2


It is almost never worthwhile to change working code retroactively merely to conform to changed standards.

There is value in precepts such as "use standard functions rather than roll your own", "minimize dependencies", etc. However, the reason these are valuable is that they save you effort that you can use in a more productive way.

In your case, you have already expended the effort. Yes, satisfying dependencies is a cost, but you've already done so. Yes, rolling your own takes time, but you've already spent the time, and you can't get it back. At this point, expending more effort in order to adhere to a principle that didn't apply when you wrote the code would be counter-productive. Just live with the non-optimal code organization.

An exception might be if your self-rolled code is markedly inferior to what the standard eventually came up with. In that case it may be worthwhile to rewrite to the standard, but only if this doesn't take more time than it saves in readability and improved further maintenance.


[ I view this question as a question about refactoring - restructuring an existing body of code, improving its internal structure without changing its external behavior. ]

Let's say that you bring new crew members (or other kinds stakeholders) into the project, who will be developing or maintaining the code base. They may be familiar with standard functions without you having to train them. They will be unfamiliar with the self-rolled utilities. In addition, standard utilities would be better documented than self-rolled.

Does this consideration justify retrofitting the old code to standard utilities? It depends. How much effort will it take? What's the risk? How many new stakeholders might you be getting?

You could write new code using standard utilities, and gradually refactor the old code towards standard utilities where it's very easy or truly beneficial.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.