I try to be rather descriptive with my function names, where possible. This occasionally results in function names in the twenty to thirty character range such as \"GetActionFr
If the function name is 'too long' then it is likely that the function itself is also too long and has too much responsibility. Many wise programmers say that a function should do one thing and one thing only. A function whose name that has to be long to accurately describe what it does is likely to be a good candidate for refactoring into multiple smaller and simpler private functions that consequently have shorter names.
In my opinion a function name should be exactly as long as needed to describe what its purpose is. If you think that the name of the function is too long, then that may be an indication of that it tries to do too many things, and should be refactored.
If a compiler has some limitations on variable names, it's often 64 or 128 characters or somewhere in-between. In the past, 32 characters have also been popular. If they do have a limit, they often just take the first n characters and ignore the rest.
General rule is that the function name provides a very short description of what it's doing. Most of such descriptions should easily fit within 32 characters. (Use CamelCase to separate words.) Since most IDE's now provide Code Completion, making errors with function names does tend to be rare. But do make it yourself easier by making sure most functions differ from each other with the first 8 characters. Something like DateCalculationAddMonth, DateCalculationAddWeek, DateCalculationAddYear and DateCalculationAddDay should be avoided. Use AddMonthDateCalculation, AddWeekDateCalculation, AddYearDateCalculation and AddDayDateCalculation. (Btw, these are silly examples but I hope you understand my drift.)
Actually, it might be better to add (group) your functions to a separate class. With above silly example, you could just create a class DateCalculation and add four (static/class) functions (AddMonth, AddWeek, AddYear and AddDay) to that class. Basically, this would be more useful when you have many similar functions which would all have very long names if you don't group them together in separate classes.
The function name is too long when it would save you work to use a shorter one.
The reason we usually go for descriptive function names is because it saves us work. (by making it easier to understand and maintain the code). So it logically follows that you should not give your functions names that are so long that it costs you extra time (making the code harder to read, for example)
Sometimes the 30-character limit in many contexts in Oracle SQL and PL/SQL felt like a terrible restriction, but on reflection it has caused us many times to think hard about how to name things so that they are quickly understood by someone reading the code later.
If we couldn't adequately describe the purpose of a table, view, function, procedure, package, etc. using 30 characters without using excessive abbreviation, it just needed a bit more thought, and perhaps an additional layer of abstraction to group related things together.
Ask yourself a more interesting question: Why do we make function names long? It's in order to describe what the function does. Well, I submit this hypothesis:
The amount of description necessary in a function name is inversely proportional to the amount of type information available for it.
To illustrate the point, if you saw a function like this...
public <A> A id(A a);
...what would you think it does? The type information tells you everything you need to know. Barring side-effects and exceptions, there is only one thing that this function could possibly do.
Of course, you are probably working in a language that allows unfettered side-effects, so that function could, say, write to a file. But if it does then its type is a lie. Working in a language that declares effects in types allows you to use very terse names without any loss of descriptiveness.