0

Yeah, the title isn't the smoothest, sorry about that.

I'm programming a property and I want to name it in the most intuitive way. Extra bonus if it's a short one. Please note that there's no emphasis whatsoever on the term being broadly known, self-explanatory nor trivially interpreted. It's good if some or all of the properties are possible to achieve but it's by no means a requirement.

There's a method for computing an area to a polygon and it's called Area. However, it's being accessed very frequently so I've improved it so it doesn't need to compute the area every time. Only if the area hasn't been computed (or needs being recalculated), the actual calculation will take place. In every other occasion, I retrieve it from the pre-computed storage.

And here's the linguistic issue. Naturally, I'd call the method

ComputeIfNeededThenStoreAndAfterwardsRetrieveArea

but that's only nice to the eyes of a computer, not a human. I could, of course, be vague on the actual implementation details and go

ComputeArea

or maybe even

ComputeCacheableArea

but it seems to me plausible that there might be a verb conveying that precise message with a fewer and shorter words. Is there such a verb, please?

4
  • You probably need to focus more on the implications of "compute if needed". Unless "if needed" really means "every time the value might have changed" (in which case just "compute" is all you need) then what you've got is some kind of coarse-grained data retrieval routine. From that link, Coarse-grained ... data is communicated infrequently, after larger amounts of computation - as opposed to fine-grained, where one can access many different (but all accurate and up-to-date) values over a short period of time. Commented Sep 3, 2016 at 21:32
  • 1
    (Personally, I'd be inclined to call it a lazy access function.) Commented Sep 3, 2016 at 21:33
  • @FumbleFingers Hats off for your lazy access suggestion. It actually is a term used in programming meaning that something is done later, when it's really, really needed, in the last second, just in case the operation could be avoided by postponing it (as long as it doesn't block the process, that is). Knowing that you're not an IT scholar, the hats being off'ed should be extra large, festive and honorable. Commented Sep 3, 2016 at 22:25
  • There is a name for this technique: en.wikipedia.org/wiki/Memoization. Commented Sep 3, 2016 at 23:01

2 Answers 2

0

What you are doing is caching results and then retreiving from cache if possible later.

Do the calling functions really need to know if the result is cached or not? If not, don't worry about exposing those implementation details in the function name, but document it in your function's comments.

Otherwise, for the functions that try to retrieve by cache, I'd just tack on _cached on the end of the function name.

0

The convention in most object-oriented languages used in the United States is to not bother the method's client with the details of the caching. (For that matter, the client usually does not need to know that caching happens at all.) For example, you might have:

class Rectangle extends Shape {
    bool hasCachedArea = false;
    decimal cachedArea = 0.0M;

    decimal Area() {
        if (hasCachedArea == false) {
            decimal area  = Width() * Height();
            cachedArea    = area;
            hasCachedArea = true;
        }
        return cachedArea;
    }
}

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .