Bad Actors in your Code

During my time in the Army, I used to get rankled when I’d see Television or Movies portray soldiers.  Generally, they’d get something wrong; and usually, it wasn’t just something minor.  It didn’t usually bug me when it was clear they weren’t trying to get it right. It bothered the hell out of me when it looked like they tried to get it right, but failed in some way that could have been prevented if they would have spent $1000 and hired a military consultant for a day.

The same thing bothers me about naming in source code.  Well, not the military part, but the ‘bad acting’ part. Names that don’t do what they say they do, or names that don’t even mean what you think they mean.  These ‘gems’ can slow down development time and reduce the level of understanding from all team members. For every new person you bring on to the team, that’s another person that has to make the mental leap from what a word means to what it is used for in your application.


Here are a few bad names I’ve seen in source code recently, and they are all from commercial applications.

timeout  – Describes how old a file should be before it’s deleted

narrative – Refers to the ‘help’ field for a form or page.

nounset – where noun can be anything, like ‘bird’ or ‘category’ or ’email’ or ‘password’. The suffix ‘set’ is added to it to denote a ‘set’ of that noun. In some cases, it refers to a ‘template’.

That’s just a few; and there are more out there, probably in the application you work on.

What’s so wrong with bad naming?

Let’s say you have a new developer come onto your team. it doesn’t matter if this developer is just out of college or if he’s a 10 year veteran. He now has to learn what those words mean.  He then has to apply those names to the intent behind them, and daily has to remind himself of what they mean, since they aren’t used in their normal context.

Here are some possible solutions for the ‘naming problem’.

timeout  – fileAgeInMinutes

narrative – instructions

nounset – nouns, or nounTemplate (This can also rely on the fact that in databases, a table is considered a collection of things; adding ‘set’ is redundant).

It’s easy to change the name of something before it’s in use; but what happens when it’s in use?

Great question — one I don’t have a definitive answer to.

If you’re king of your particular hill, then you decree that the name is changed.

If you aren’t, then all you can do is raise awareness and push to having it changed in all parts of the application in the main branch, and make it an architecutural change for the next relief. It’s important to keep documentation up to date (preferably in source code) so that new developers know that in the ‘old’ version, it was called something different.

What are your thoughts? How do you deal with ‘bad names’ in Source Code?


Leave a Reply