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?

  • 1
    approximateResult(data)? Answering this question probably needs a specific function name.
    – Jasmijn
    Jul 6 at 11:05
  • First Approximation, Estimate, CalculateResult(enum Accuracy) ?
    – Ewan
    Jul 6 at 11:12
  • @Jasmijn I like to have multiple functions that do the same thing start the same way, which is why I avoid prefixing variations of them. That said, approximateResult(data) has the issue I mentioned which is that it doesn't indicate the drastic speedup. You may take calculatePairwiseRelation(data) as an abstract proxy for the function name if it helps. Jul 6 at 11:28
  • @Ewan The accuracy sadly isn't a direct parameter, it is indirectly (and unpredictably) related to a certain batchSize that is used for the approximation calculation. Jul 6 at 11:29
  • Does your language support default arguments? If so, why can't you use default arguments to specify a default batchSize that you believe gives the best tradeoff between performance and accuracy while letting callers choose to override it for improved accuracy or improved performance at the expense of the other?
    – Thomas Owens
    Jul 6 at 11:54

6 Answers 6


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.

  1. calculateResult_h(data)
  2. calculateResultHeuristic(data)
  3. 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);
showNote("(Estimated. Calculating final result...)");

final.then(result => {

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.

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.


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

  • 2
    That's a great point about intellisense etc, however for my particular programming language a very specific IDE is used which has poor support in that direction, making one more reliant on descriptive names. Jul 6 at 12:58

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.

  • Yea I guess I could do calculateResult(acc) { if (acc == 1) /* do precise, slow Alg */ else /* do approximate, fast Alg */ } Jul 6 at 12:16
  • Instead of "acc" use "accuracy", it clearly communicates purpose. That's one of the thing, Instead of abbreviations we should always use complete word wherever possible.
    – user130934
    Jul 6 at 12:19

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.


I would go with PreviewResult(data).

I mean, it's kinda like the result, but not quite the same, as it isn't as precise. It is "blurry", so to speak. If you need the full "resolution" of the result, then ask for the proper "CalculateResult".

"Preview" gives the idea that it is like the true thing, but not quite the same. A sampling, a "low-resolution" version of the "true" result. If the user needs the full thing, they can always go for the OG calculateResult to get the full "picture".

If you don't want to prefix your function, you can go with calculateResultPreview(data). Gives off the same idea of blurry result, without prefixing.

  • 1
    “Preview” is only meaningful if you know the context. I’d expect an image with “preview” written across it. “approximate” expresses exactly what the method does, up to the caller to decide if it is useful.
    – gnasher729
    Jul 6 at 16:58

Not the answer you're looking for? Browse other questions tagged or ask your own question.