Today we're going to discuss the Single Responsibility Principle(SRP) and how it applies to writing javascript functions. When writing code it's easy to get carried away when trying to solve some kind of problem and write line after line of grabbing, manipulating and passing around data. That in turn makes it just as easy to end up with very bulky yet working functions. The job gets done right? Sure, but when it comes down to it, it doesn't just look bad it handles bad.
That's where the SRP comes in. It's a pretty self descriptive principle but let's talk about what it means and why it applies to writing good code. SRP means that every function or method in your code has one single responsibility and functions for one specialized role. It doesn't do this and that, it simply does this, or it simply does that but never both. Now that applies to good coding because not only does it add possible reusability and versatility to your code base but it also cleans it up and makes it easier to troubleshoot any current and future issues that may appear.
One thing you will hear repeatedly in coding culture is that you can spot bad code when you see a function handling too many things. Think about it like this for a moment. You have a machine that accomplishes many things but it stops being able to do one of the things. The only way to fix it is to tear the whole machine apart and fix it but once your done another function of the machine is now not working. Now imagine this scenario. You have a machine with many attachable parts that each have their own functionality and one of them breaks. You can then just grab the one attachment and fix that part specifically as it's what's causing the problem without it affecting the machine as a whole.
Another reason to apply the SRP to your coding practices moving forward is because of another core coding tenet, keep your code DRY. Don't repeat yourself. As you write out more and more functions and features on your application or web-page you'll find that a lot of them do very similar things if not the same thing with different pieces of data. At that point your writing the same code inside multiple functions when you could just break each thing down to it's base functionality and piece them together for what you need. As opposed to just creating the tool to get the job done create the building blocks that allow you to build whatever tools are needed for the job. You might be asking "Well how do I know what building blocks I would be needing until I know what the tools are?", and that's where refactoring comes in. It's okay to build your function out and make sure you're able to reach the end result you need but it's best from that point to take a look at your code and break it down its base units and separate them into their own individual functions. Chances are you can use one of those pieces you created in a future function and won't have to rewrite it again and again.
Lastly, imagine working on a team or in a pair programming session and someone asks you to check out their function and maybe help them troubleshoot it. Would you prefer to see a wall of text in that single function? No of course not. We as coders skim. We don't read every single line in the code cause a lot of it isn't immediately relevant to what we're trying to address. If the code is compartmentalized you can look where is necessary and tackle the problem at its root. So for the sake of your code and for the sake of other coders learn the principle, love the principle, and live the principle. That's all from me today.
Top comments (0)