7 ms·
You could have just moved the repetitive math into separate functions and called them from the resize functions. The resize functions themselves only looked re
by kstenerud 3y ago
You could have just moved the repetitive math into separate functions and called them from the resize functions.
The resize functions themselves only looked repetitive because they were forming an interface, which is why refactoring them away was wrong. But the math they performed is a perfectly valid target for cleaning the code.
- Tade0 3y agoExactly. Seems like the obvious way to go and this is what I typically do. The end result is of course a huge bag of small, pure functions, but they're easy to test and refactor so it's never an issue.
- gpderetta 3y agoAnd you can re-inline and modify the special cases in the future if necessary.
- mattkenefick 3y agoEspecially since it was a refactoring, it's generally better to handle those in stages if you're working with a team. There are lot of ways/patterns for solving the same problem... but tearing apart an existing interface being used by others isn't a good start. The best part about abstraction is that you can modify the underpinnings to be more flexible without hurting the rest. A good step would be to create more flexible math functions underneath, like you're saying, and leave the rest alone. Afterwards, there can be deeper conversations with the team about how they want the interfaces to communicate to provide an obvious facade but an abstract implementation.