A function is named for its purpose
The question's premise, i.e. what a function's name should reflect, isn't quite right. From your comment on candied_orange's answer:
What I am not satisfied with when using a [function] name such as those you suggested is that they are not descriptive of the [data type] being returned.
Function names should not describe their return value, at least not inherently. A function should describe what the function's purpose is.
If a function inherently needed to be named after what it returns, every function (that returns something) would need to be called returnFoo, returnBar, ... Clearly, this isn't all that useful if it were the primary naming rule.
There are cases where a function has no real purpose other than returning a value which is already trivially available, at which point it can be useful to name the function after the value it returns. But it's not a blanket rule that should be blindly applied.
When a function does something and then returns the subsequent result, the primary purpose is doing something, and returning the result is just a secondary consideration (since it'd be pointless to not return your achieved result, in most cases).
Think of it this way: if you want to return multiple values, you could approach this two different ways:
- Wrap all needed return values in a DTO class and return an instance of that class
- Return multiple values (for languages that support it).
In either case, the method does the exact same thing. The only thing that changes is the returned type(s). Following your logic, these methods should have different names, since they're returning different types.
That doesn't make sense. The function has the exact same purpose in either case, so its name should be unchanged.
The only valid justification for picking different function names is related to overload conflicts, i.e. in case you want to implement both methods and they have the same signature.
But this is not related to the question on what you should name a function when there is no overload conflict.
A function's purpose (and thus name) is contextual
In a question that solely focuses on naming decisions, you've not really focused on the most important information: context.
a function that walks through an automaton to find the state for the longest prefix of a word contained in the automaton as well as the length of the prefix
Notice your usage of "prefix" in describing both values. This strongly indicates that your multiple return values are all prefix-related information. This leads us to understand the purpose of your function: it finds a prefix and returns information on it.
a function that walks through an automaton to find the state for the longest prefix of a word contained in the automaton as well as the length of the prefix
The primary purpose of the function is to find the longest prefix. Returning data related to that prefix is a secondary consideration.
The name of the function should reflect its primary purpose:
def findLongestPrefix():
return "Hello, World!", 0
Note: There may be a contextual name (e.g. "prefix details", "prefix information", ...) which is already defined/understood in your domain and reflects the information that you're trying to return here. If that is the case, such a contextual name would be better than the "prefix" name I chose to use here. You have more contextual awareness than me, so adapt my suggestion accordingly.
Note: I'm not sure which language you're using (python?) and what it's casing conventions are. Adjust the casing as appropriate.
Documenting the returned values
my concern for being indicative of the data structure remains, especially for dynamically typed languages such as python
I'm aware that this probably isn't applicable to Python, but C# specifically added named tuples to ensure that developers could give each value an appropriate name which describes each individual returned value. There is a clear benefit to labeling return values (when there is more than one).
Python doesn't allow for it (AFAIK), so you're going to have to live with that. This is a design consequence of the language you chose to use.
But as much as I agree that lack of clear typing can lead to issues like these in dynamically typed languages, I disagree that you should therefore foist this return type information in the method name itself.
While not impossible, it doesn't really fix the issue. You still don't get the benefits of strong typing, the function name still needs to be read and understood by humans, and if a human needs to look it up anyway (and gets no compiler validation), then proper function documentation trumps function naming. Don't try to inject documentation in the function name.
Instead of forcing a terse bit of information in the function name, instead you should clearly document this function and what it returns.
Whether documentation comments suffice or you instead use an external documentation tool is up to you and what your company prefers to use.
a name such as get_longest_prefix_data is at least indicative that the returned type is not just a string or a state, but a structured value, so it is not misleading at all, and encourages the developer to check to documentation
If you're a developer working in a language where there is no strongly typed return value, you'd have by default check a function (or its return type) to ensure that you know what to expect it to return.
There shouldn't be a need to name functions specifically so you can remind developers to look up documentation on things they aren't yet familiar with.
