So, you’re wired in. Code is darting from your synapses through the ends of your fingertips, sprawling gracefully onto the devenv-framed canvas. You know precisely how this little soft machine must do its dance, and the IntelliSense can barely keep up with the science dropping from behind your eyeballs.
Hold on—those calls there should be a separate class altogether. Right-click. Add. New.
Seriously. What should you call it?
Naming is important. Naming is difficult. Naming is an under-taught and underrated developer skill.
In fact, I’m going to go as far as to say that if you’ve never been properly bound up on the New dialog, in a fix not unlike like the one I describe above, you don’t care enough about giving things good names in your code. And odds are that you have left a trail of miserable developers in your wake, weeping like lost children and wondering which end is up in that fragile pile of Visual Basic they just inherited from you.
I’m just guessing about the Visual Basic.
Assert.IsTrue(Coding == Writing);
If you are a developer, you are a writer. Like it or not. A good writer first considers their audience, then tunes in the best voice in which to address that audience. This principle holds as solidly for the halting cadence of a 4GL in a line-of-business app as it does for the email cast in the King’s English that you just sent to your boss.
Who, then, is our audience when we’re earbudded and thusly nerding at velocity? The computer, you may answer, with a jerk of the knee. If you’re a bit more clear-headed, the compiler. Both true, of course. But the oft-overlooked audience is every other dev on the planet who will ever touch this code ever. You are carbon copying them on what you are telling the machine to do, and your voice to them should be just as unmuddied.
Presumably, these other developers are human beings, held together with skin, and electrified with sensitivity to the subtlety of written language. And (sit up for this part) fully subject to the psychology of that sensitivity. These words and symbols you are cranking out don’t just live in machine instruction; they echo through meetings, emails, and conversations that all translate to real human choices and actions. Once it leaves your capable hands, the quality of the decisions made around that variable, class, component, application, or system depend largely on how well the name you bestowed upon it summarizes its reason for existence.
Viewed through this lens, your christening skills can make or break a work of software.
There are coding conventions that ebb and flow depending on your programming dialect of choice. But these are not those. This is not about camel-casing, Hungarian notation, or brackets having their own lines. This is about communicating with other developers through code.
Here are a few pointers that come to mind:
- Focus on what, not how. Name things based on what they do, not on how they do it. There will likely be a need for a component that provides data about your customers, long after WCF becomes a thing that even your customers know is laughable clutter on your résumé. DotNetStuff.CustomerWCFService, bad. CustomerInformation, good.
- Take your time. Or don’t. The time you spend giving something a name should be directly proportional to the scope of the thing you are naming. Is it a string variable local to a property, holding a comma-delimited list for a few lines until it’s split up and spun into a Collection<string>? Go ahead and call it list. But that Web Application project probably should not have a namespace of MahNewKittehWebz.
- Don’t call it New. Replacing the OrderProcessor? Cool. And that may be the NewShinyOrderProcessor you’ve got there now. But man, is the team replacing it three years hence going to have some facepalmworthy conversations. This naming strategy just shows a complete lack of respect for the space-time continuum and its future inhabitants.
- Don’t call it a Configurator. Ever.
- Thou shalt not append the word Object. For the love of Stroustrup. We know it’s an object—give it a name. This may be a tough habit to break, especially for those readers who were coding when the Earth’s crust was still congealing, when OOP first came into fashion. But it’s simple to overcome, nonetheless. Go ahead and name your type with the –Object suffix. Then, have a deep, cleansing breath, and rip it off. Like a band-aid. UpdateCartResponseObject becomes UpdateCartResponse. Sit still and embrace that awkward naked feeling until you realize that the new, less redundant name does the job quite nicely.
I’ve got more bullets. With bold bits and snarky bits, some of them with entertaining/relevant links. And I would use them, but for the fact that this is not about my ample narcissism of small differences. It’s about clarity, and forethought, and choosing words carefully because they mean things. In whatever medium you choose them.
And I’d much rather just challenge you to bring these qualities to the naming in your code.
You know. For the lost children.