Chris Dragan's Corner

One day we’ve decided to import a piece of code of a significant size from another project. It made perfect sense and allowed us to avoid spending months to write what others have already written. This happens quite often in many projects, because code reuse saves time and money.

After making it work, days later we’ve discovered saddening truth. Lots of resource leaks! The source project was sloppy with resources, because it did not matter much in that particular project and perhaps they don’t have the right tools to even know about the resource leaks’ existence.

A few hours spent with a leak checker revealed that even though the code was written in C++, it was written in a C-like fashion, with objects allocated directly with new and stored in raw pointers without ever being released. Some containers were semi-hand crafted, though they used STL containers underneath, but holding raw pointers.

Lots of programmers given such code would scream: “Rewrite from scratch!”. But is it really such a good idea? I don’t think so. I don’t doubt that there are projects which absolutely need a rewrite, but in many cases refactoring comes to the rescue. In the end refactoring is a less costly alternative. If there are tests for the original code (hopefully!), the approach is to slowly fix the code. In this particular case the first thing is to gradually introduce the right resource allocation and management mechanisms which are not prone to leaking.

The size of the task of importing foreign code is hard to estimate. One of the reasons is that taking code from one project and putting it in another, new environment will make the code behave differently enough to reveal obscure bugs. On the other hand if that code remains maintained and shared between projects then its quality will improve. So everybody can benefit from reusing, and if needed refactoring and fixing existing code.