The ability to write reusable code is considered a hallmark of excellent programming, and with reason. Having reusable code means that a team won\u2019t have to write separate entries for every piece of software that performs a similar function; this greatly reduces the collective workload and frees up time for more meaningful work.<\/p>\n\n\n\n
At the same time, the importance of reusable code can be overemphasized. It is not unheard of (particularly with the contemporary glut of motivational speakers in tech) for junior developers to be advised that all<\/em> their code should be reusable, otherwise they are not doing a good job.<\/p>\n\n\n\n Reality is, of course, not quite as straightforward. While writing reusable code is important, there are actually cases when code should not<\/em> be reusable \u2013 or, at the very least, when such a quality should not be in the forefront of your mind.<\/p>\n\n\n\n Don\u2019t believe me? Here are 4 cases in which you should not<\/em> be thinking about reusability!<\/p>\n\n\n\n Reusability is an essential principle of development, but that doesn\u2019t make it the only<\/em> essential principle. Simplicity is arguably even more important, and should be paramount in any project you embark on.<\/p>\n\n\n\n Sometimes, on a good day, you will come up with code that is not reusable, but that is beautifully simple and elegant, making it easy to read and understand. If the only way to make it reusable is to render it perceptibly more complex, then it\u2019s usually best not to touch it.<\/p>\n\n\n\n The trade-off will typically not be as obvious (you can\u2019t \u2018measure\u2019 how simple a line of code is), but as a general rule of thumb, reusability should not be pursued when it comes at the expense of simplicity.<\/p>\n\n\n\n Code is not a static thing, and the parts of it performing the most complex functions in a project will probably have to be tweaked with a certain frequency. If you expect your code to be amended, but you aren\u2019t certain when or how often that is going to happen, then you should probably write something that stands alone, as future changes to what you wrote might reverberate elsewhere in unpredictable ways. The last thing you want is to have to mop up everywhere in your code each time you change a variable.<\/p>\n\n\n\n Bear in mind, the sort of thing for which reusable code is most useful is also the stuff that typically doesn\u2019t need to be changed too much \u2013 aleatory functions, like for example connecting to a database \u2013 so \u2018one-off\u2019 solutions, in this case, are unlikely to waste time on the long run. This leads me neatly into the next point, that code should not be reusable\u2026<\/p>\n\n\n\n The whole point of reusability is to save time. If trying to make all your code reusable is slowing you down as a developer, then maybe it\u2019s best to forget reusability, at least for a while, and just focus on getting your projects done on time. Remember that if you stay within schedule, you can always use the extra time to refactor the code later and make it reusable then.<\/p>\n\n\n\n As a developer, you will spend much if not most of your project time working under a tight deadline. Making all of your code reusable may sound like the best option on paper, but in practice, you\u2019ll have to learn how to make compromises in the name of time-management. Sometimes that does mean ditching reusability.<\/p>\n\n\n\n This is related to #3, inasmuch as it\u2019s another thing that can be changed later in time, but this one is more about the conceptual approach at the beginning of a project than the time-squeeze at the end of it.<\/p>\n\n\n\n Basically, the idea is that your first priority when beginning to prototype code should be that it works<\/em>, with reusability a secondary consideration. I wouldn\u2019t go so far as to say that code should never<\/em> be reusable in the early stages of a project \u2013 if you can make it reusable on your first go, then great \u2013 only that it\u2019s not the priority.<\/p>\n\n\n\n Code has to be useful before it can be reused. Get the true essentials done first.<\/p>\n\n\n\n As we stated at the outset, reusability is<\/em> important to programming. Indeed, one of the reasons React is so central to our course<\/a> is its reusable component ecosystem, which is both powerful and widespread.<\/p>\n\n\n\n However, it won\u2019t surprise you to learn that nobody would pay a developer for work the entirety of which could have simply been reproduced from somewhere else. Any product you\u2019ll be working on should have a unique selling point the uniqueness of which will be reflected in your code.<\/p>\n\n\n\n#1 When it trades off with simplicity<\/h2>\n\n\n\n
#2 When it will have to be changed<\/h2>\n\n\n\n
#3 When it\u2019s not time-efficient<\/h2>\n\n\n\n
#4 When you\u2019re looking for early results<\/h2>\n\n\n\n
Final thoughts<\/h2>\n\n\n\n