3 ms·
I disagree strongly. This code is very maintainable: it does not have dependencies, it is trivial to test, it is wickedly short, and with the appropriate comme
by enriquto 7y ago
I disagree strongly. This code is very maintainable: it does not have dependencies, it is trivial to test, it is wickedly short, and with the appropriate comment there is no confusion regarding its purpose. Also, its field of applicability is clear from the context: replace this code with a call to fsqrt if you happen to have a fast hardware implementation of it. It is the most easily maintainable code, ever!
- fteem 7y agoBy "the appropriate comment" you mean, and I quote: "// what the fuck? "
- chii 7y agothe one maintainability metric, and i think is the most important one, is whether it's easy to modify (to make it do something slightly different). You'd be hard pressed to write an inverse square cube without basically rewriting the whole function. There's nothing that can be reused. The only saving grace is that it is side-effect free, so replacement is trivial, unlike a lot of other code that's not maintainable.
- quickthrower2 7y agoThe question is how likely are you to need it to do something different, and what are the different things it might need to do? This will depend on the domain, but making things too flexible hampers maintainability too.
- wruza 7y ago>inverse square cube You mean inverse cube root? I believe the geometry ain’t easily upgradeable this way.
- munchbunny 7y agoYour metric is only applicable within the context of the problem domain. In 3-d graphics, the inverse square root (1 divided by the square root of x) is an extremely common operation (such as for normalizing vectors), but the inverse cube root pretty much isn't used, so it's safe to assume you will not need to extend it to arbitrary powers. As the designer of the code, you would understand that the inverse square root is a standalone problem.