4 ms·

I have never understood the practice of using a verb phrase ("get") for functions with no side-effects. To me it makes more sense to name the function after the

I have never understood the practice of using a verb phrase ("get") for functions with no side-effects. To me it makes more sense to name the function after the result, i.e. Instances, InstanceIds, AllInstanceIds etc.

halfmatthalfcat 5y ago
Preforming I/O is a side effect. Accessing an external database is a side effect. Using a verb to imply external access to "get" some resource is appropriate in this instance.
codr7 5y ago
The advice I once got and since internalized is to reserve 'getX' to give a hint that something happens besides returning 'X', lazy initialization is a common use case.
- 8note 5y ago
  I think of ensureX as getting x whilst initializing it if needed
wvenable 5y ago
Like other's have said, I might use "Get" to signify that this is a complex operation. Although I prefer more descriptive words like "Fetch" or "Find". So FetchInstances() is expensive (each time it's called) but the property Instances is cheaper or only expensive on the first access.
- augustk 5y ago
  But then the name of the function is somewhat tied to its inner workings. What if you change the implementation so that it returns a cached value? To quote Michael Caine, an interface should "Be like a duck. Calm on the surface, but always paddling like the dickens underneath."
  - wvenable 5y ago
    > But then the name of the function is somewhat tied to its inner workings. Not necessary tied to it's inner workings but more tied to how you should use it. There are good reasons that a function might not cache it's value -- maybe because you want that fresh data each time. The name is the signal to the user how they should use it. I expect an "Instances" property to give me the same values each time. However with "FetchInstances()" I would store that result in my own variable if I want to keep referring to those instances. > What if you change the implementation so that it returns a cached value? That's a different function then. The semantics have changed significantly.

halfmatthalfcat 5y ago

Preforming I/O is a side effect. Accessing an external database is a side effect. Using a verb to imply external access to "get" some resource is appropriate in this instance.

codr7 5y ago

The advice I once got and since internalized is to reserve 'getX' to give a hint that something happens besides returning 'X', lazy initialization is a common use case.

8note 5y ago
I think of ensureX as getting x whilst initializing it if needed

wvenable 5y ago

Like other's have said, I might use "Get" to signify that this is a complex operation. Although I prefer more descriptive words like "Fetch" or "Find". So FetchInstances() is expensive (each time it's called) but the property Instances is cheaper or only expensive on the first access.

augustk 5y ago
But then the name of the function is somewhat tied to its inner workings. What if you change the implementation so that it returns a cached value? To quote Michael Caine, an interface should "Be like a duck. Calm on the surface, but always paddling like the dickens underneath."
- wvenable 5y ago
  > But then the name of the function is somewhat tied to its inner workings. Not necessary tied to it's inner workings but more tied to how you should use it. There are good reasons that a function might not cache it's value -- maybe because you want that fresh data each time. The name is the signal to the user how they should use it. I expect an "Instances" property to give me the same values each time. However with "FetchInstances()" I would store that result in my own variable if I want to keep referring to those instances. > What if you change the implementation so that it returns a cached value? That's a different function then. The semantics have changed significantly.