The vast majority of code we write is intended to serve a single purpose and once employed in that purpose it never sees the light of day again. That is, however, a bit of a waste of your valuable time, when it’s perfectly possible to write your code in such a way that it can be recycled and put to use in many different purposes.
The challenge is that writing recyclable code is quite different to writing what might be termed as “throw-away” code. With the latter kind of code, you really only need to be concerned with how other humans interpret your code instructions if you haven’t written those instructions perfectly. When you write recyclable code, however, you need to do it in a very specific way, and you really need to think about how anyone, including yourself, will understand the code you have written at some point in the future.
Doing things in this way takes much more time and effort than ordinary coding, however it has the advantage that you never have to write the same exact function twice. As stated, you will need to do everything in a certain way in order to be sure that your code really can be used again for other purposes.
It’s worth mentioning that recyclable code is not necessarily the same thing as a plug-in. When you create a plug-in, you are developing some code that anyone can take and incorporate into their website and easily generate some effect from it just by changing a few parameters.
Recyclable code is different in the sense that it is not necessarily static and it’s not necessarily intended for distribution outside of your own organization. No matter what, it is essential to make sure you use the correct process, described below.
1. Become a master of organization
When you create code with the intention that you can later reuse it, that won’t help you much if you can’t find it. You need to do a really good job of naming, storing, and classifying your code files.
2. Be aware of what is “application specific” and what is “generic”
Nearly always there will be some code that is really specific to your particular application and it couldn’t be used in any other way. As you create each chunk of code, you should be deciding whether it is application-specific or generic code. Ultimately you want to create a lot more of the latter than the former, and there’s a good way to do this that I’m going to describe in step 3.
3. Separate code from values
Hard-coded variable values can present a problem when you want to use code in new ways. A better way to do it is to store your initial variable values in something like a CSV file, and then load those values in when the application starts. This method also allows you to easily change initial variable values without tampering with your original code file.
4. Try not to hard-code any values that don’t absolutely have to be
This basically means you shouldn’t hard-code any values at all, with one exception which is the name of the file that will be loaded containing all the soft-coded values. That file should always be accessible relative to the root path of the application, or you could have problems if you move the files to a different operating system.
5. Avoid putting spaces in file names
Just because you can put spaces in file names doesn’t mean you should. It can potentially create problems for you if you move your files to a different operating system or file system. For example if you move your files from ext4 to FAT, you could find that you encounter problems. Interestingly the Windows operating system will display the names of files with illegal characters in them, but won’t allow you any access to those files, even if all you want to do is rename them.
5. Comment everything verbosely
At the time you write your code, you know exactly what it’s going to do. But allow a few years to pass and it’s quite possible you will have forgotten your intentions. It’s the same story also when you’re using somebody else’s code, because unless they’ve provided verbose comments you will have to spend precious moments analyzing and interpreting what they have written.
6. Avoid creating dependencies
One of the biggest flaws in most reusable code scenarios is that you can end up with huge chains of file dependencies. This happens because people write their code chunks in specific ways and include them in a specific order without documenting why. Then before you know it, you end up with a Left-Pad scenario and everyone panics when some chunk of code that your application is depending on goes AWOL for some reason.
You can avoid this kind of meltdown by making sure that every chunk of code can easily be swapped out for another one, documenting like crazy, and of course making back up copies of every chunk.
Documentation should include what a file is, what it does, and why it is loaded in the particular place that it is loaded. This eliminates potential dependency problems, because any portion of code can be recreated because its purpose is known.
7. Format all your code really neatly
Obviously it’s a good idea to always do this anyway, but it’s especially important to do this when you are writing reusable code. You also should maintain a very consistent style of coding and not change it. For example, if you tend to write your constant names in uppercase and variable names in camelCase, you should do that with absolute consistency.
8. Every chunk of code has a specific purpose
Your mission is to understand what that purpose is. You have to avoid allowing multiple purposes per chunk. So for example if you have a chunk of code that loads in the initial variable values, it should not do anything else besides that. Your next chunk of code should be handling the next required operation. How strict is this rule? Well, your main function shouldn’t do anything other than make calls to all the other functions.
It’s a lot harder to write good recyclable good than anyone would think before they attempt it. No matter what your initial intentions may be, you are likely to find that about 80% of the code you write will end up being application-specific rather than generic. Most people rave about recyclable code without actually having any clue how they will ever actually use it in the future, with the end result being that they create more work for themselves, which is the opposite of the goal. Hopefully this article has helped you to avoid that fate.
header image courtesy of DKNG