Naming things

Thu 01 June 2017

Naming things – choosing a string of characters to represent a given expression – can be frustrating and difficult. This might be obvious, but the abstraction of referring to a block of code with something memorable and human readable greatly increases the ease of programming. Whoever first realized that we could use memorable words like MOV and GOTO instead of numeric opcodes was responsible for a huge advance in programming language design. In a sense, every time we abstract away a function, script, module, or program using a name, we’re building on that simple idea. Being able to reference other parts of a program is important in its own right, but it isn’t nearly as effective if you have to refer to your function by say, its location in memory, rather than a name that describes what it does. However, when we choose names to take advantage of this abstraction superpower, there’s an inherent conflict between brevity and being descriptive. Deciding how to name things has been referred to as one of the hardest problems in programming1. I’ve been thinking about how to do a better job at this lately, and here are some notes I’ve made on the topic. Some of them might seem sort of contradictory – I think that’s just an indication of how naming things is complex and nuanced.