Personally I find that line of reasoning entirely unconvincing.
-
By extension of the outlined reasoning, naming becomes more important even for typed languages that support type inference because of the implied nature of the type of an entity. Developers usually welcome type inference within a typed language - but this argument essentially implies a tradeoff of an added naming burden because of the lack of proximity of the type specification.
-
The argument ultimately conflates the notion of the type of an entity and the role of an entity. I’ve always preferred that the name of an entity identifies its role rather than simply restating its type. I’ll grant that there are some types that are so specialized that they were designed to only fit one role but even these types can be (ab)used in surprising ways.
At the other end of the spectrum are types like integer
- which could be used in the role of a counter, quantity, scaled currency value, identifier, etc., where in many cases the valid range of the entity is mostly implied (though some languages have ways of specifying a derived narrowed type). But even when we have, lets say, three currencies, naming helps to differentiate each of the specialized roles that these currency values have.
f
is not a perfectly decent variable name for a file pointer if there are other file pointers … several files related to input, lookup, output - each with it’s own specialized, subtly different role.
So I actually suspect a misinterpretation of the circumstances where one can get away with short names - while the type can provide some of the information there can be other peripheral information that helps out. e.g.
m = increment(n)
The name n
already implies an integer (though that isn’t reliable) but the name of the function adds further evidence to what the role of n
might be - though in this isolation we still don’t know if we’re counting an iteration, accumulating the quantity of widgets in a bin, or increasing the fare on a taxi meter.
m = increment(n, step)
The above example demonstrates that often the entity which is the focus of the processing is usually the one that can get away with the shortest name because:
- Everything is about that entity
- The role of the entity is likely identified by the name of the “package” that contains the processing that revolves around that entity, e.g. the function name.
And ultimately
increment(n)
could still be a very poor name if it’s role is actually
next_widget_id(current_id)
i.e. the fact that the next id
can be generated via a simple increment is an implementation detail - what is important is that we can somehow get the id
of the next widget that needs to be processed.
So the guideline is still: “effective naming matters” - regardless how hard it may be. But it’s still just a guideline. Long names aren’t necessarily effective but at the same time short names shouldn’t become an avoidance strategy for convenience (or laziness) sake.