When is a function name too long?

Question

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 "GetActionFromTypeName" or "GetSelectedActionType". At what point do functions get too long to manage (not too long for the compiler)?

Answer 1

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.

Answer 2

Trying to avoid subjectivity:

When names get to be about 1/3 of whatever your typical line length is, then you're stretching it. At 1/2 line length you're too far gone. One statement per line gets pretty tough when the names take up the whole line.

Beyond that, most IDEs support completion (thereby saving the programmer from actually typing most names out fully), so the more important thing to do, in my opinion, is make sure that the name is as unique as possible as soon as possible.

Answer 3

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.

Answer 4

When you start to think it :)

Answer 5

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.

Answer 6

If there's a shorter, but yet descriptive way to name the function, then the function name is too long.