When considering code reusability, you should first identify the reasons that make you want to think about how to ensure reusability of code in a project. We all want to get the job done as easily as possible and reusing the hard work you did before seems like a perfect way to finish a project faster.

However, the questions you need to answer are “Should I reuse code” and only if the answer to that is a resounding yes, should you care about “How to ensure reusability of code in a project?”. Let’s tackle the two questions in order.

Also read: What Is Code Quality? How Can Code Quality Be Measured?

Code reuse – Should you reuse code?

Nine times out of ten the answer to this is going to be a “no”. And if you think it through, you’ll realize that the allure of getting that code that worked in a previous project and copying it to this new project is more trouble than it’s worth.

The main reason you’ll run into trouble is that the code you’re trying to reuse wasn’t designed to be reusable, and when you initially wrote it you had a very specific use case in mind with specific limitations and test cases. 

Your code will be designed to accomplish the goals stated in that use case, which means that, unless you’re fortunate enough to need the exact same thing, in the exact same way. You’ll have to change your code, at which point you’re not reusing it really.

Another thing to consider when eyeing up code for reuse is the amount of documentation you or the original developer provided. The questions you need to ask yourself are:

• Are there quirks in the code that account for specific requirements the original use case had but which you do not have now?
• Are there limitations on the inputs or outputs the code generates?
• Are there known bugs in the code?
• Or, has the code even been extensively tested outside of the core use case it was built for?

Unless you are fortunate enough to be trying to reuse code written by an extremely diligent developer in the team, the documentation will not explain in great detail all the things you need to know to make sure the code you’re trying to reuse does not behave in unexpected ways. 

This means you’ll have to read and understand the code before you reuse it. No matter if the code is yours or someone else’s, revisiting code months after you have written it, if you don’t work with it daily is going to be just as slow, if not slower, than writing it again for this new case.

Code reuse vs. Inspiration

One last thing to mention before we start talking about when you should consider reusing code is an inspiration.

Inspiration is not reused. 

If you don’t know how to do something, or if you can’t remember how you did something and you revisit old code – copy some of it and change it to accomplish your new goal. This is not reused. 

You don’t have to write everything from scratch. If you’ve changed how the code works, removed unnecessary functions and objects, and just generally written efficient readable code, that has some sections copied from code that you or others have written before, that does not reuse, that’s just development.

When should you reuse code?

You should only be considering code reuse in a few limited situations, here are two an example:

• You are working with identical data objects across multiple projects and you don’t want to re-write them every time. For example: let’s say you have multiple apps and they all need to manage users.

  In most cases, the data you need to hold on a user and the actions you can take on objects will also be limited. This means you can probably safely reuse your user class across these projects, this is a very classic example of code reusability in OOPS (Object Oriented Programming).

• You need to perform a function in a standardized way across multiple projects.

  Let’s say your team has decided on a preferred way to log events and errors across projects. Instead of each project implementing this, it’s far more efficient to implement it once and reuse it everywhere.

As you can see the connection is the need for the same thing to be done in the same way across projects. The moment that “thing” starts becoming less the same, that’s when you start getting in trouble because now your code needs to be able to handle all the variations.

How to ensure reusability of code in a project?

At this point, you’re probably thinking: “I know I shouldn’t but if I need to, could you tell me more about the reusability of code with examples?”

When you think your code might need to be reusable it pays to stop thinking of it as code that belongs to a project and think of it more like its own standalone project. 

You’re actually using “reusable” code all the time. Every time you import a public library, use open-source code, or a plugin built by a fellow dev, you’re reusing someone else’s code either directly, or benefiting from it by calling it through an API.

Every time you import a public library or use open source code, you’re reusing code. With that in mind let’s look at some ways to build reusable code:

1. Thinking of it as its own product. What would it look like if you were creating an External API? To help with this process make sure that your code only does one thing. That might mean that you might have to chain multiple of these “reusable products” to obtain the desired effect, but it also means that the scope of this code is well-defined, testable, and easy to understand.

2. Implement business logic by using your reusable self-contained component products. In essence, you’re building two things… first the reusable component, and then the business logic code that uses the reusable component.

3. Think abstractly about your code. To have reusable code you have to minimize the impact business logic has on the reusable code, if a restriction is not needed from an engineering point of view it shouldn’t be a restriction just because your business logic requires it – that should rest with the not reusable business logic code. For your code to be reusable it should work with other applications that have similar requirements.

4. Keep your code simple. When first building your reusable components, don’t add code that you will not be using in your current business logic implementation, as that would add complexity that might not be needed, and make the code harder to test and document. Also, don’t repeat yourself, the goal of reusability is leveraging these components, so avoid duplication in code, just use the atomic, well-defined components you created in downstream components.

5. Allow easy extension. While you should keep your initial code as simple as possible, don’t code yourself into a corner. It is very likely that you will need to extend these classes and components later so always allow for future extensions when business cases require it.

6. Test everything. Your code needs to be reliable, write both unit and functional tests for your components that will allow you to easily extend in the future without worrying about breaking any existing functionality.

7. Document strategically. Ideally, your code should be mostly self-documenting, but remember to document reasons why certain decisions were made as that might be less clear when you visit this code in the future. Document the why more than the what.

And since you must think of it in this way you might as well separate it out from your main code from the very beginning. If you think you’re going to need to reuse it, make it an asset you import into every project, including the first one – be that a library, plugin, or whatever.

Conclusion

You’re probably thinking, this sounds like it would take a lot more work and time than just writing the code I need now, and you are right. Reusability requires investment, and you should only consider reusability when the use case for it is good enough to require the extra investment in planning, time, testing, and coding. Reuse is not free, it’s expensive, however in a select few cases it’s cheaper than having to do the same thing repeatedly.

Get in touch with us at Wolf-Tech for a code reusability and code quality audit