I recently wrote about Easy Programming, my pseudo-methodology for “keeping going” in the face of difficult or tedious tasks. Since then, I’ve observed an aspect of my workflow that, while seemingly among the easiest of tasks, can be the most limiting to my productivity. What is this devastating conundrum? The challenge of naming code.
I must have a christening hang-up. I get all cold-footed when the time comes to name a class, source file, method or function. Even variables! There’s a lot of pressure to come up with a name that is both instantly descriptive of the concept being represented, while also compatible with the prevailing code style, easy to pronounce, type, etc.
Could it be that the most mundane task, giving names to the commodities we trade in, could be the hardest aspect of programming?
In light of my recent thinking on Easy Programming, I was inclined to think that the best solution is to just forge ahead. Don’t let myself get caught up in such antics. If I can’t think of a class name within 5 minutes, just call it something and get on with the show. After all, after everything is working, I can always rename it if I feel strongly about it. I was getting happy with this conclusion when Jonathan Wight of Toxic Software made a statement that tipped my thinking in the other direction:
“Generally if I can’t think of a name for a class it means that when i come to refactor the code that the class wasn’t well thought-out in the first place.”
Well, shucks. That sounds downright obvious now that I’ve heard somebody else say it.
Zachery Bir pointed out that such thinking is common in OOP circles. A bad name is often identified as a code smell – something that stands out in code as a sign of potential lurking problems. An article on good naming supports exactly what Jonathan was getting at – that a badly named entity begs for refactoring.
So the dilemma becomes this: how do I keep my job easy, and name things correctly, and avoid spending an eternity doing it? My conclusion is that naming is important enough that it deserves a good length of consideration. Don’t be afraid to give yourself an hour or more! Do other stuff and let it sit in the back of your mind. You’re not wasting time. What you’re doing is designing on autopilot. When you think of the right name, it will serve as a specification for what you need to do – and specifications lead to easy programming. If you can’t deduce the right answer yourself, seek help from coworkers or the web. The articles on the C2 Wiki, including those cited above and this one on “meaningful names” go into detail about some techniques that might help you settle on the right name. There’s gotta be a right name for the class. What does it do? What should it do?
Sometimes you simply won’t be able to figure it out. A programming defeat, and it stings! At last it may be in your best interest to follow my first instinct: simply forge ahead. If you know you can get the job done and fix it later, your time may be better spent on future refactoring than on present-day moping around, trying to come up with the perfect name. Use your failure as a exploratory design experiment. It’s OK, you failed. We all do it. But whatever you do, don’t waste your time trying to come up with some “almost appropriate” name for your mistake. Don’t fake success by giving it some prestigious name that blends into the background. Name it SmadoodieCracker, or GodDamnImASuckyProgrammer, or something equally delightful. Better yet, pick a standard template and name all of your cop-out classes using this scheme: SuckyClass001, etc. Now you can do a global search for your smelly names.
Many programmers will feel hesitant to adopt such a practice. Your self-esteem is not fully developed, and you fear that coworkers will see what a fraud you are. Surely your boss will decide that you’re not senior developer material after all. And here we thought you were an infallible genius! This all may be true on a sucky team, but on a good team they’ll appreciate your candidness. And when browsing the sources to SmadoodieCracker, should inspiration strike and present a clear vision of what the class should do, they won’t think twice about overhauling your ugly mess. You owe them a beer, now.
Other people fixing your code? The easiest programming of all!