readable, short identifiers

I often hear the supposed wisdom that the use of short identifiers in code is a bad practice. There’s the obvious argument that it’s hard to tell what the shorted, contrived names mean. Another is that modern IDEs have good-enough autocomplete that makes it quick enough to type reallyLongDescriptiveNames.

Here are some of the short names I fairly-regularly introduce in code without explanation:

on autocomplete

Only really heavy IDEs and editors have anything approaching decent autocomplete (Visual Studio is the best known example). That’s problematic because many people can’t or don’t want to use those IDEs. I use a mix of Atom, Sublime, and TextMate, none of which have particularly sophisticated autocomplete.

Disambiguation is still a problem in ‘advanced’ editors, since there are many identifiers that start with a common prefix. There’s NS in Objective-C, but at least it’s short. Imagine if it had been expanded to NextStepString for all classes in the whole ecosystem! In Apache Flex, there are over 20 class names in a particular package which start with the prefix AdvancedDataGridBase. In JavaScript, you often have to type document. before even beginning to disambiguate between the 157-or-so properties an methods it has. document.createXYZ in particular has a bunch of options, so you’re either going to have to hit the down arrow a bunch, or type out a bunch of characters before you hit the right one. Some editors sort symbols by recency of use (in time or distance in the document), which helps a bit in these cases.

I haven’t found an autocomplete implementation that will complete document.qsa to document.querySelectorAll, much less d.qsa or `dqsa“. I’d enjoy trying something like that out if anyone knows of something similar. It’d be sort of an acronym-based sloppy programming.

on context and redundancy

Imagine a function declaration:

function initHitForBranch(branch:Branch)

The word ‘branch’ is repeated 3 times: once in the function name, once as a parameter name, and once as a type annotation. This is decent given that ‘branch’ is a relatively short word, but we’d be in trouble if we were dealing with xylophones. x or xylo would be great as parameter names given that anyone editing the body of initHitForXylophone will see the association between names in the declaration. Even if the body is really long (which it probably shouldn’t be), the shorted names are clear enough. (Unless a xylophone is a sprite-like object with coordinates, then x would be a bad choice.)

Repeated long names are tiring and obscure syntax (and comprehension) by spreading apart structural aspects of code. Lambda syntax for functions (like x => x * 2) is nice not only because it’s easier to type, but also because it puts the focus on the meaningful parts of the code rather than boilerplate. Reading a line like:

var advancedDataGridGroupItemRendererAutomationImpl:AdvancedDataGridGroupItemRendererAutomationImpl = new AdvancedDataGridGroupItemRendererAutomationImpl()

…it’s hard to tell if the three things are even identical, versus:

var e:E = new E()

Or, to be more charitable:

var iRenderer:IRender = new IRenderer