I thought this might be kind of fun (fun can also be read as “upsetting”), so I’m giving it a shot. It’s pretty frequent as programmers we go back and revisit some code and find ourselves shaking our heads at what we see. These code smells often don’t show their faces when they’re being created, so don’t beat yourself (or anyone else) up just yet. Common signs you’ve stumbled upon a code smell are when you find yourself saying:
How could that co-op have possibly coded this?! Blast those interns!
Or
What the heck was John thinking when he put this together?! Does he not have a brain?!
Or
No wonder we find so many bugs in this part of code! Look what Jane did!
But it never truly hits home until you get one of these:
What is this crap?! This is by far the worst code I have ever seen. How cou–Oh. Wait. I did that.
Code is always a work in progress. If it’s not, it’s because you’re writing a one-off script or your code doesn’t do much of anything. Our skills as programmers are always transforming as are our perspectives. You’re guaranteed to have one of these moments if you’re programming long enough and look back on your code that was once The Pinnacle of Awesome.
With that said, I’m hoping to share some code smells that come up as I see them in my own projects or when talking with friends/colleagues. You might be about to type up one of these code smells, so pay attention! I don’t know how frequently I’ll put one of these posts together, but I might as well start now. Every time I get a handful of code smells I’ll try to push something out to The Interwebz.
The Stink List
Code Smell #1: Your variable is named or prefixed with “temp”, “tmp”, or some variation of “temporary”. This is unnecessary. If you have a variable, by definition it’s something that’s temporary. Nothing in code lasts for forever. You’re just lengthening a variable name or not putting enough thought into a good name.
Code Smell #2: Your variable is one character long. The exception to this is probably for simple loops. You almost always see code that is iterating over a counting variable “i”. Maybe that’s not so bad. If you nest three loops and you have for i, j, and k, things can get messy. If you find you’re using single character names outside of loops… STOP. Just name your variable something that won’t be a puzzle for someone one day from now.
Code Smell #3: You prefix things as “New”, “First”, “Last”, or some other definitive/completely ambiguous position. If you have something that’s “Newest” now and then tomorrow a new one is made, you now have to go change all of your code that used “Newest”, because it’s not the newest now. Same with something like “old” or “new”. It’s the “old” one now, but what happens when your “new” one becomes old because of a third generation? Now you have two olds and a new. What the heck are you going to do? Pick a good name from the start.
Have your own code smells? Share them in the comments. If you’re interested in more learning opportunities, subscribe to my free weekly newsletter and check out my YouTube channel!
Affiliations:
These are products & services that I trust, use, and love. I get a kickback if you decide to use my links. There’s no pressure, but I only promote things that I like to use!
- RackNerd: Cheap VPS hosting options that I love for low-resource usage!
- Contabo: Alternative VPS hosting options with very affordable prices!
- ConvertKit: This is the platform that I use for my newsletter!
- SparkLoop: This service helps me add different value to my newsletter!
- Opus Clip: This is what I use for help creating my short-form videos!
- Newegg: For all sorts of computer components!
- Bulk Supplements: For an enormous selection of health supplements!
Quora: I try to answer questions on Quora when folks request them of me!
Although I agree with #2, another place it’s useful is LINQ lambdas. someList.Where(f=>f.blah == “yes”); I don’t see the point in writing out a longer name, given the context of the list.
Thanks Don,
That’s a good point. Really, when the scope of your variable is so small that name length competes with ease of reading the code, #2 sort of falls apart. The goal is supposed to be making the code easier to read and understand, and generally having non-descriptive names doesn’t help at all with that. I’d actually say that picking a descriptive name within your lambda would help someone not familiar with lambdas, but for anyone who uses them regularly it would likely be seen as clutter.
Great point, and thanks again for the comment.
Pingback: Code Smells – Issue Number 2 « Dev Leader Dev Leader
Make sure to check out the second installment right here.