I’ve seen a lot of bad code written before. This is partially because I’ve written a lot of bad code myself in the past (and for that matter, I still do sometimes). The first step to solving any problem is to admit that you have one. This means you need to recognize bad code when you see it. Here is a list of some serious coding mistakes that I see time and time again.
1. Don’t copy and paste!
I get a lot of pushback on this from everyone, but I feel really strongly about it.
While copy and paste is great for moving things around, it causes problems, too. Like duplicating existing code where normally you could use a function or a loop to accomplish the same task or creating 5 copies of the same function that each have only one line of code that separates them from their bretheren.
You should re-type the code by hand instead. This seems to involve more effort (especially if your typing skills are not up to par) but it will also help you find issues in your code faster, since it gives you more time to think about what you are writing.
By using copy and paste you are distancing yourself from the meaning of the code and its existing design problems. By typing it out again your brain has to process everything you are writing and you might jump up and say to youself, “wait… why am I doing this again? This is way too much work…” where as if you had copy and pasted it you would not notice.
2. Avoid vague or non-descriptive variable and function names
It is very crucial to have meaningful variable names. I find myself getting confused every day at work because of variable names that have no meaning. Remember that what makes sense to you at the time may not make sense to the rest of your team. It might also not make sense to you later. It does make the naming situation a little more challenging.
Taking the time to clearly think about the name of a variable could save you and your team hours when trying to debug code later on.
In the past I have even done this to myself. I will pick a name for a variable, put the code down and come back to it months later and then try to use the same variable to do something completely different than what it was intended for—just because the name was suggesting something else.
This is such an important topic that I will provide some examples of bad variable names. These are taken from real production code.
- superAddressBookList
- superRelativesList
- result
- data
- pid
- obj
data, pid and obj are probably ubiquitous in the programming realm but I am going to tell you exactly why I hate them. data can mean anything. Everything is data. You might as well name your variable everything. Because as far as I’m concerned, that’s what’s in it.
The same goes for obj. I’m assuming obj is an object, but what kind of object? Give me a little more information about what to expect from this object and how I can use it. Even something like personObject or animalObject sounds better to me. Although my ears still twitch every time I hear the word “object” being used, I guess that’s what you might call a personal problem.
I don’t like pid because while the id part is likely not a Freudian reference the letter p could stand for anything. This variable could be storing the process id of a thread, or a product id (in an eccomerce situation) or even a purchase id. God forbid there’s a purchase id and a product id! Then what do we do? pid1 and pid2? Don’t be lazy. Type. If you are working in the field as a software engineer I have earth shattering news for you: you are being paid to type.
Here are some function names that also don’t make any sense:
- void dataLoadToPage()
- void sendDataToPage()
- void supportTabActive()
I’m still not sure how the first two are different
supprtTabActive based on the name might be a boolean function, or it might be a void function that activates the support tab.
This is one is a really good example loop that I found:
$.each(function(bi, people) {
//code does something in here
});Seeing the word “bi” and “people” next to one another in code makes me wonder what’s really going on in that loop.
3. Review Your Code
Seriously. Take a break after you’ve gotten your stuff to work and re-read what you’ve written. If you have someone else you can pull in to review your code with you, that’s even better. They will help point out certain things that you might not see since your eyes have become accustomed to the code.
Sometimes finding a problem with your code is like trying to find those misplaced car keys. You know you put them on your desk somewhere but since you know the layout of your desk so well there are certain places your brain will rule out searching automatically; those are precisely the places you need to be looking.
4. Be Consistent
Adopt a consistent style of coding. Things like tabs vs spaces, how many tabs, when to indent, which lines to place the opening and closing brackets on, etc.
Also be careful when naming your variables. If you are using camelCase or under_scores or CAPS_AND_UNDER_SCORES. Remember that just because you use camelCase for your local variables doesn’t mean that you should rule out using CAPS_AND_UNDER_SCORES for constants, for example (or something like that).
5. Pay Attention To Logic
Watch out for setting variables and conditions and then repeating the exact same code unconditionally. I’ve seen a lot of code that looks something like this:
if (weWantToHaveFun) {
getBeer();
throwAParty();
fireLaserBeams();
}
else if (weWantToHaveFunWithoutBeer) {
throwAParty();
fireLaserBeams();
}
else {
fireLaserBeams();
}In this code, we fire laser beams no matter what. It would be smarter to pull that line outside of the if statements entirely. Also notice that you are repeating the code (fireLaserBeams()) 3 times.