Deliberately Ugly Names

Posted On October 13, 2019

There is a humorously devilish piece of satire by Andy Yurisich that “instructs” us to give variables names like ínt, god, and LancelotsFavouriteColor – all in the pursuit of job security through inscrutable code. It’s brilliantly creative writing and I encourage you to read it; as a parody piece and not as an instruction manual.

Jokes aside, the need to name variables properly is a topic that occupies center stage in the discussions on software craftsmanship. One reason is the never-ending difficulty associated with the problem. The late Phil Karlton called “naming things” one of only two hard things in Computer Science. Another reason is the significant variance in scoping rules [1][2][3], naming conventions [4][5][6], case-sensitivity [7], and maximum allowable length[8][9] between different programming languages.

Almost all of the constraints, rules, and conventions are geared towards creating names that are easier for programmers (humans) to read: they encourage aesthetically pleasing names. However, there are a few reasons to actively abandon aesthetics and to go for deliberately ugly names (DUNs). And these reasons are not motivated by the tongue-in-cheek job-security advocated in Andy Yurisich’s article. 

One such reason is to avoid name collisions in global namespaces. Another is to call attention to parts of the code that should not be used at all, or used with extreme caution.

Ugly naming to avoid name collision

If you are developing a library or plug-in that will inject variables in the global namespace of the program where that library will be used, you may want to consider a DUN to minimize the likelihood that there will be a name collision.

This scenario implies that you have a few conditions in place:

1. The language of your library allows variables in the global namespace.
2. The name you are injecting in the global namespace refers to a symbol (variable, function, etc.) that will be used frequently and ubiquitously. (Otherwise, the justification for it being accessible globally is weaker.)
3. The name you’ve chosen isn’t already used by any other popular library or framework.

There are several libraries in JavaScript that fulfill these conditions and therefore use DUNs for their important global variables. The $ in jQuery and the _ in Underscore.js are obvious examples. However, I am inclined to think that the now-defunct Bookmarklets was one of the earliest JavaScript libraries to encourage and explain the need for deliberately ugly names to avoid name collision.

Ugly naming to dissuade from using ugly code

My colleague Alexander Nied recently found this line of code while debugging:

This reminded me that Martin Fowler had called attention to this phenomenon in his article titled FlagArgument. These DUNs serve an important purpose. They remind developers that something wrong is likely to happen if the thing with the ugly name is called. This is a much better way to signal bad code than documenting it externally. Every single instance of a DUN is an automatic, inescapable reminder of the technical debt that is incurred by that usage. It’s also fairly easy to grep the DUN and to get an objective measure of the size of this technical debt.

Summary

Giving names properly to things is hard. Giving ugly names properly to things is even harder. However, if you are trying to avoid name-collision, or trying to warn people from using bad code, it may be a good time to use a DUN – a Deliberately Ugly Name.

References

[1] C sharp scoping rules
[2] C scoping rules
[3] Java scoping rules
[4] Ruby and Rails naming conventions
[5] Javascript naming conventions
[6] R naming conventions
[7] Case sensitivity in Common Lisp
[8] Maximum identifier length in C
[9] Unlimited length identifiers in Java