3 ms·
I constantly try to improve how I write my code. The last couple of years I’ve been involved in a couple of projects that’s required rebuilding a few times over
by bubblebeard 2y ago
I constantly try to improve how I write my code. The last couple of years I’ve been involved in a couple of projects that’s required rebuilding a few times over because the project managers kept changing directions and was always in a hurry.
For one project I eventually managed to convince them to let our team write a more general purpose library to conserve time in the future. And this has paid itself of several times over.
When we write code it’s important we do consider how it may be utilised in the future. Since we cannot make exact predictions it’s better to make methods as small as possible instead to reduce the amount of time spent on refactoring (since this is unavoidable). This also helps us to create solid, more future proof, tests for our business logic.
You don’t need to follow a strict set of design rules, but general guidelines is a good idea. Like trying to follow SRP, avoiding more than x nubmer of lines for your method bodies and trying to avoid nestled code.
- Hasu 2y ago> Since we cannot make exact predictions it’s better to make methods as small as possible instead No, please don't. Separate your functions based on what they're doing, not an arbitrary line count. If it takes 50 lines to do what's necessary, a 50 line function is absolutely fine. You know what isn't fine? One operation split into 50 different subroutines that are all useless on their own unless composed together in order. Make your interfaces small, not your functions.
- bubblebeard 2y agoI agree with you, I didn’t say that quite right. In my mind this is actually pretty much what I meant, though I completely see how it can be misinterpreted. Line counts, like most other design rules should really be more like guidelines. Thank you for helping me clarify myself mate!