Method names for getting data

It is all about consistent semantics;

In your question title you use getting data. This is extremely general in a sense that you need to define what getting means semantically significantly unambiguous way. I offer the follow examples to hopefully put you on the right track when thinking about naming things.

  1. getBooks() is when you are getting all the books associated with an object, it implies the criteria for the set is already defined and where they are coming from is a hidden detail.
  2. findBooks(criteria) is when are trying to find a sub-set of the books based on parameters to the method call, this will usually be overloaded with different search criteria
  3. loadBooks(source) is when you are loading from an external source, like a file or db.
  4. I would not use fetch/retrieve because they are too vague and get conflated with get and there is no unambiguous semantic associated with the terms.

Example: fetch implies that some entity needs to go and get something that is remote and bring it back. Dogs fetch a stick, and retrieve is a synonym for fetch with the added semantic that you may have had possession of the thing prior as well. get is a synonym for obtain as well which implies that you have sole possession of something and no one else can acquire it simultaneously.

Semantics are extremely important:

the branch of linguistics and logic concerned with meaning

The comments are proof that generic terms like get and fetch have no specific semantic and are interpreted differently by different people. Pick a semantic for a term, document what it is intended to imply if the semantic is not clear and be consistent with its use.

words with vague or ambigious meanings are given different semantics by different people because of their predjudices and preconceptions based on their personal opinions and that will never end well.


Honestly you should just decide with your team which naming convention to use. But for fun, lets see what your train of thought would be to decide on any of these:

  • GetBooks()

This method belongs to a data source, and we don't care how it is obtaining them, we just want to Get them from the data source.

  • FetchBooks()

You treat your data source like a bloodhound, and it is his job to fetch your books. I guess you should decide on your own how many he can fit in his mouth at once.

  • FindBooks()

Your data source is a librarian and will use the Dewey Decimal system to find your books.

  • LoadBooks()

These books belong in some sort of "electronic book bag" and must be loaded into it. Be sure to call ZipClosed() after loading to prevent losing them.

  • RetrieveBooks()

I have nothing.


The answer is just stick to what you are comfortable with and be consistant.

If you have a barnes and nobles website and you use GetBooks(), then if you have another item like a Movie entity use GetMovies(). So whatever you and your team likes and be consistant.


It is not clear by what you mean for "getting the data". From the database? A file? Memory?

My view about method naming is that its role is to eliminate any ambiguities and ideally a need to look up documentation. I believe that this should be done even at the cost of longer method names. According to studies, most intermediate+ developers are able to read multiple words in camel case. With IDE and auto completions, writing long method names is also not a problem.

Thus, when I see "fetchBooks", unless the context is very clear (e.g., a class named BookFetcherFromDatabase), it is ambiguous. Fetch it from where? What is the difference between fetch and find? You're also risking the problem that some developers will associate semantics with certain keywords. For example, fetch for database (or memory) vs. load (from file) or download (from web).

I would rather see something like "fetchBooksFromDatabase", "loadBookFromFile", "findBooksInCollection", etc. It is less sightly, but once you get over the length, it is clear. Everyone reading this would right away get what it is that you are trying to do.