The Problem with Smurf Speak

You know how the Smurfs substitute almost every word for smurf? This is known as Smurf speak in the comics and TV show. We software developers also Smurf-speak. What we tend to do is put our company or product in the names of modules, classes, and functions. Classes like McDonaldsPendingOrder and GoogleDocsMainMenu have redundant prefixes. Yet PendingOrder and MainMenu are perfectly good names and give you the same information. I am going to outline why you don’t need to Smurf speak, and give a few tips to help you avoid it.

No, no, I asked you to bring us a smurf! A smurf to smurf!

Only developers Smurf-speak.

Why do only developers Smurf-speak? Obviously because we write the code! If you work for the Smurf company, classes like SmurfUserProfile, SmurfAddressInfo and SmurfUserID seem logical - they model the Smurf’s account information. But imagine if your company branded everything in the office. Do you drink a Smurf coffee on your 11.00 a.m. break? Do you deal with the result in the Smurf men’s bathroom? Is your job title Smurf front-end developer? If you find this example far fetched, substitute Smurf for Google, Microsoft, or whatever your company might be. Branding goes on material intended for the public’s eye. It doesn’t belong in the code base. Call a spade a spade, not a Smurf spade.

It discourages software reuse.

If you add your company or product name to a class, you are saying “this class is just for us”. This couples your solution to a specific domain. Code reuse is an important tenet in software development, codified in principles such as DRY. Smurf speak discourages reuse. It can compel you to write a less elegant solution that’s hard-wired to the specific problem you are solving. Even if your code works in a different project, names might be off-putting. A branded class name is the first step to make your class distinctly *non-*reusable. Name your classes for re-use and you will write for re-use.

Your product or company name can change.

I used to work at an operational intelligence company. Years before I had started, they changed their name from Visual Tech to Black Data (fake names for this article). I only learnt about the name change when I saw files like viz-tech-line-chart.js and viz-tech-data-label.js - that prefix was everywhere! A name change is an expensive exercise that requires a company to update almost everything: business cards, sign in the lobby, little cheap pens, etc. But code doesn’t care about your company name. Users don’t see it. It will still compile. Yet using the old company name in your code looks shamefully anachronistic. In Black Data’s case, removing every reference to the old company name would have been a huge effort that didn’t justify the benefit. Save trouble for yourself and make your code impervious to branding changes.

Wait, where do I work again?

Luckily it’s easy to avoid.

Now you understand what Smurf speak is and why it’s insidious. I have three tips to help you avoid this habit.

1. Name impeccably and name well. Describe your class or function concisely. Don’t reference your project, company, product, department, or anything unrelated to the entity at hand.
2. Think open source. Name your code as if it’s a public resource that another team might use. Better yet, write reusable code!
3. When writing any kind of identifier, ask yourself, would this be out of date if any company branding changed?

Though naming things is hard, it’s easy to remove redundancy. Less Smurf speak means nicer code.