Naming a method that does the same thing faster but only approximates the result?

Question

Presume I have a function that does some precise calculation on a large amount of data, call it calculateResult(data).

This function gets very slow with increasing size of input.

Luckily, I only need the approximate result in some cases, so I write a second function that does the same calculation much faster but with a small error margin in the result.

What's a good way to name that function? I'm struggling to come up with a concise name. My issues with the following suggestions are:

• calculateResultApprox(data) - Makes the function look superfluous, as the benefit of speed is left out.
• calculateResultFast(data) - Makes the original function look obsolete, because it looks like this one does the same thing, just faster; the small error in the result is not indicated.
• calculateResultFastApprox(data) - My current best idea but I don't like how long and clunky it is.

Better ideas?

Answer 1

Honestly I think your problem is that there are too many perfectly reasonable names. All of these are OK, especially if they come with good docstrings.

1. estimateResult(data)
2. approximateResult(data)
3. quickResult(data)
4. fastResult(data)
5. previewResult(data)
6. calculateResult(data, timeLimit: number)
7. calculateResult(data, accuracy: number)
8. calculateResult(data, method: simulated | estimated | phone a friend | etc)

(For options 1 - 5, I'd also throw a docstring on calculateResult to inform folks about the "fast" version.")

The "right" answer depends entirely on the context of the invoking code and the mindset of the person writing that code. What's the purpose of the faster result? Is it for the purpose of a preview? Is it for a learning or searching algorithm (like A*)? Can your "faster" version be considered a hueristic?

If so, all of these (and others) are also perfectly reasonable, if not more-so.

9. calculateResult_h(data)
10. calculateResultHeuristic(data)
11. calculateX(data, heuristic: true | false)

Alternatively, depending on your invocation context and purpose, you could return a result that contains both values, wherein the "final" result is "pending". You could even have the "final" result evaluate lazily (i.e., only if awaited). Using TS as an example:

const { preview, final } = calculateResult(data);
showResult(preview);
showNote("(Estimated. Calculating final result...)");

final.then(result => {
  showResult(result);
  showNote("(Final)");
});

There are so many perfectly sane options! You just need to figure out what pattern, purpose, and conception your caller has in their head.

So, ask yourself some questions. (Give the answers to your rubber duck — out loud, ideally.)

• What's in your caller's head?
• How did the person looking for the faster result ask you for it? Was it, "Hey, this is too slow. Can I get a preview result while the final result is churning away?" Was it, "Hey, we don't actually want wait on this level of precision. Can I just get a heuristic?" Or something else entirely?
• Have you discussed the naming question with the team or consumer?
• Is this a two-way door? (Can you easily change the name later if you don't like it?) ... If so, roll the dice and change it later if it causes confusion.

Answer 2

The essential thing about your method, the thing that I absolutely need to know, is that it gives an approximation to the result; not as precise as the most accurate result possible.

I wouldn’t mention that it’s fast. There’s quicksort which does a perfectly accurate job at sorting, just using a clever and fast algorithm. If you call it fast I still expect it to be precise. If you say “approximate” then I expect it to have some advantage. Less memory, less time, and I expect it to be documented.

“approximateResult” is perfectly fine. It’s common sense that you didn’t create a less accurate method just for fun.

Sometimes you will have a name like “exactResult”. When it’s straightforward to create a reasonable result but takes a lot of effort to make it even more precise. I’d expect that such a function comes with extra cost, and it’s up to me to decide if it is worth it.

Answer 3

Comments and Documentation have a bad name, but it doesn't mean they are completely useless.

Usually with this kind of thing there will be a variety of methods of calculation with various tradeoffs and its expected that the user will understand them. Calculate_BreadthFirst PiMonteCarolo etc. You don't expect the name to completely explain the algorithm. You have documentation/comments/intellisense etc

Answer 4

Sometimes it's really hard to come up with method names, especially if you are on tight deadlines.

Example of function names you have given(calculateResultApprox(data), calculateResultFast(data),calculateResultFastApprox(data)). I think those names can be confusing since they sound similar.

1. one of the things I would suggest Avoid using similar names for multiple functions/methods. Why not add an accuracy parameter in the function? You still might need to further divide that function if it grows too lengthy.
2. I would recommend reading the Clean code book by Robert Martin.
3. In my experience peer review process is always helpful for things like this.

I hope that is helpful.

Answer 5

calculateResultFastApprox is fine. I'd go with calculateResultFastButWithErrorMargin

Long/clunky doesn't matter, accurate & descriptive does. Nobody's going to worry about typing it in a few times.

So long as it's documented, call it the thing that makes sense.