When I first started coding I joked that I would never understand it because there was so much algebra type code. Then I was introduced to all of the acronyms engineers used to construct their projects and it got even more confusing.
So let me break it down for you:
Single Responsibility Principle
This one I think is my favourite – it does what it says on the tin. Everything you build should be broken into segments that one do one thing. This can traced down from turning monolith projects into smaller microservices so each project has one responsibility, to each method and function only having one job.
Considering naming conventions to figure out if you have done this successfully. If you were to name something based on what the function actually did, are you able to write “this function does x” or do you find yourself saying “this function does x and then y and z”. If it is the latter, consider breaking things down more.
Why should I do this? Following principles isn’t simply something we do because someone years ago said we should. There are benefits for us as engineers. For example,
using SRP helps break projects up into manageable chunks. New engineers can jump into the code and not feel the need to untangle large functions in order to decipher what is going on.#
Broken up code is also easier to read. I’ve seen legacy functions 100s of lines long and I find myself drifting off before I’ve reached the end. It’s simply unruly.
And finally, by following this principle makes life easier because it improves reusability. If the functionality that you need is hidden in the depths of a 130 line long function, then you will need to rewrite the code again where you need it. If instead the functionality is broken out into its own function, most of the time you can call it where you need that functionality added and save yourself writing it again (that’s another principle: Don’t Repeat Yourself (DRY)).