4 ms·
80% pulled out of thin air. If the logic is non trivial, always extract into separate function or file, because future maintainance not code reusability.
by chakkepolja 5y ago
80% pulled out of thin air. If the logic is non trivial, always extract into separate function or file, because future maintainance not code reusability.
- laputan_machine 5y agoRead my post fully. > Creating an abstraction that makes no sense is worse than just having code being there twice The key point being 'that makes no sense'. If you have experience as a software engineer you understand that most 're-use' isn't completely de-duping a function, but instead you see it being abstracted out into a more generic fn that can handle two or more _slightly different_ use cases. This typically makes the original intent of the fn difficult to understand Some programmers do this and then pat themselves on the back, repeating the 'DRY' mantra to themselves and everyone else around them. 80% isn't completely pulled out of thin air, the vast majority of fn abstraction leads to a less understandable (therefore less maintainable) codebase.