Re:On over-engineering; finding the right balance
by Hasu on Wednesday September 11, 2024 @08:24AM
(#41510677)
> 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.
Re:On over-engineering; finding the right balance
by bubblebeard on Wednesday September 11, 2024 @09:50AM
(#41511387)
I 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!
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.