I disagree. If you are relying on a well-known algorithm, you should identify the specific algorithm. Look up Square Root Approximation in Wikipedia, and I see nothing about the Newton-Raphson method or anything that looks like it will match the code. If I read really carefully, I see a link to Newton’s Method, which in fact does match the algorithm here. That’s only after wasting a huge amount of time reading other approaches which don’t match the given approach.
IMHO, always default to descriptive method names for algorithms, and always include wiki-friendly (or dictionary-friendly, or old-school-encyclopedia-friendly) terms. Therefore:
* Newton-Raphson Square Root Approximation
Some purists will say too much implementation detail, but IMHO you want that implementation detail in there. If you change the implementation to a different algorithm, it is right and proper that you should have to visit every single use of the method in your codebase to make sure the new algorithm will work as well there as the one you are targetting. And, if it doesn’t, you then end up with NRSquareRootApprox() and ISRSquareRootApprox when you add in an Integer Square Root method for greater speed in some situations.
The other option, adding a constant parameter identifying the specific method, IMHO, is more clutter. The algorithm is fundamentally different, and different methods to attain similar results may require additional parameters (ex, a max iterations parameter might make sense for one approach but not another). You also end up with either an enumeration specific to that one method, or an inability for the compiler to check the validity of the enum being passed in (ie, you have implemented NR and ISR, but not BSR; what happens when the BSR constant is passed in?) The enumeration and the code implementation get too far separated in all but the simplest of algorithms, and so will get out of sync.