Reusable code is the holy grail of development. If you can write something once and use it over and over again, you’ve just saved yourself valuable time. But complicated, single use spaghetti code seems to be the norm, especially among newer, inexperienced or self-taught developers.
Making the switch to writing reusable code will not only save you countless hours of rewriting similar blocks of code, it will revolutionise the way you think about application structure and you will be outputting higher quality, easier to understand code.
What Is Reusable Code?
Reusable code is exactly what it sounds like, it’s code you can use more than once. This can mean a function you use more than once in the same application, or a block of code you use in multiple different applications, it just has to avoid being over-complicated and bespoke.
How Do I Write Reusable Code?
Making the switch to writing reusable code can be daunting at first, it requires a shift in perspective and you often have to change the way you handle application structure. Stick with the steps laid out below and I promise when you look back on the code you used to write you will wonder how you coped.
#1 Make all of your functions single purpose
We are all guilty of breaking this rule, you know what I mean. We have all written 300 line long functions that perform 10 different separate actions, and sure it works, but what happens when you then need to perform just one of those 10 actions? Now you are needlessly recreating functionality. Instead, you should split each of those 10 actions into their own function and call those functions from the original.
Even if you never plan on reusing the functionality, giving each function a single purpose creates inherently better code. It makes it easier to debug, easier to unit test and easier to read. Speaking of unit tests…
#2 Test Driven Development
This has always been somewhat of a sore-point for a lot of developers, myself included, and I personally don’t practise what I preach in this regard but if you are struggling this can give you a real boost. Test driven development in a nutshell is writing a unit test that would return a successful result for the function you want to create, and then creating the function to pass the test.
I wont go into the pros and cons of test driven development here, that’s an article for another time, but this style of development is great at leading you to creating single purpose functions. Test for the outcome you want, and then create that outcome.
#3 Write DRY code
This one is nice and simple, dry code stands for Don’t Repeat Yourself. The whole point of reusable code is that you don’t have to write the same, or similar things twice. If you are often repeating yourself, chances are the code you wrote in the first place wasn’t reusable enough.
Instead of repeating yourself with a slightly altered bit of code, look back at the original and work out what you could do to make it work for both situations. Often this will take you slightly longer than rewriting the code, but it means that if you need to use it again, chances are you wont have to write anything. Possibly even more importantly, if you need to make a change to how the code works, you now only have to make the change in one place. If your code is repeated, you have a lot of changes to make, some of which you might miss.
#4 Use a Snippet Manager
The points so far have focused on how to reuse code from within the same application, but what about reusing code across applications? I’m sure you have had a piece of code you know you have written before, but you can’t find which application you wrote it in and so you give up and write it again.
This problem can be avoided with a snippet manager, but there is a lot more information on what these are and how to choose the right one for you in my earlier post: 5 Code Snippet Managers That Will Change The Way You Write Code.
Something unexpected I found when I started using a snippet manager was that the code I wrote ended up being better quality. Knowing that I was going to want to save the section of code I was writing into my library, I spent longer making it cleaner, more efficient and more reusable.
#5 Keep The Business Logic Separate
This is kind of the same point as #1 but I see it enough that it warrants it’s own point. All business logic, whether that’s API controllers, Database calls or class declaration, should be separate form the bulk of your code. Just like with the first point, if you need to use any of the functionality tied in with your business logic, your going to have to rewrite or re-purpose it, and that will only lead to trouble.
Top comments (0)