What Makes Code Bad?

If you can’t identify bad code, you can’t possibly fix it

Jun Wu
Jun Wu
Sep 2 · 5 min read
@yungnoma unsplash.com

Imagine this: You’ve been procrastinating working on one part of the project. After postponing for a week, today is the day that you plan to venture into that legacy codebase and take a look at what’s been done. The thought of it scares you. You know that the offshore team has touched this code over the years. You know that the code is about five years old. You know that you were brought in to make improvements. Rather than scrapping the whole thing, management decided to “reuse” the code due to budget issues. Now, you are in a foreign country. You hope that what’s waiting for you on the other side is “Good Code.” But, you know that there’s a 95% chance it’s simply “Bad Code.”

You start your day with a giant mug of coffee to make the process less painful. Within a few minutes, you come in contact with a specimen of code that is just awful.

Spaghetti Code — by Jun Wu

Not only does it resemble the drawing that your three-year-old just made, but some of it also resembles your three-year-old’s favorite food.

By identifying exactly how bad the code is, you can potentially re-argue your point to management that it’ll take twice as long to fix than to rewrite it.

Unreachable Code

This is a code that will never be reached unless the logic is changed.

For example:

function {} {
return x;
z=a+b;
}

The fix: Remove it.


Dead Code Including Lazy Classes

This type of code is completely redundant or doesn’t do anything.

function() {
a+b;
}
orfunction() {
c=a+b;
c=a;
c=b+c;
}

The fix: Rewrite the logic or remove the code.


Large Classes

If it takes 20 minutes to figure out the logic in one class, it’s probably time to ditch it. How many lines was that? It read like an entire chapter.

The fix: Refactor.


Circular References That Lead to a God Object

This kind of code seems to go around the corner and come back to the same destination. It can lead to the creation of a God object, an object that “knows too much or does too much.” It’s an example of an anti-pattern.

Image from Wikipedia

The fix: Refactor the code or design and split it into independent groupings.


Speculative Generality

Code someone put in there to set up for features that were supposed to happen in the future but never did.

The fix: Remove the code.


Hard-Coding

This is the easiest to spot and easy to prevent. Each time you change the value, you have to modify the code. It’s considered an anti-pattern. Usually, it’s done temporarily until the project frees up resources to add a dynamic solution that will allow the user to input the value.

The fix: Create a dynamic interface to allow the value to be changed.


Magic Number

A number that just shows up and is directly used.

function(){
for(int i=0; i<10; i++) {
}}

In this case, 10 is the magic number. The fix: Replace 10 with a variable that is initialized with the value 10.


Long If(Condition)

This is logic in an if statement that’s so long, different lines are used to simply accommodate the logic.

if(get_data(data)=success || (reuse(data)&&cut_data(data)==success)||(reuse_again(data) && cut_data(data)==success))

Solution: Use the style guide of the particular programming language to format these long if(conditions).


Sequential Coupling

I.e., methods that must be called in a particular order. For example, you have a “begin” method that must be called before a “start” method before a “drive” method.

The fix: Use the template method pattern.


Overuse of Inheritance

Too much inheritance in object-oriented programming leads to tightly coupled, non-flexible code. You can, however, focus on composition instead.

Here’s a good example of this at neethack.com and the solution.


Not Using Core Programming Language Features

This one is less obvious. But, there’s a reason a certain programming language was chosen for the project. A good example in Python is using loops for simple tasks rather than list comprehension.


Overly Complex Comments

If you have comments that are in large blocks or overly complex, it’s probably a warning sign that the code needs to be refactored as well.

The fix: Refactor by extracting methods or variables.


Message Chain

A message chain is a teacher talking to Toddler A, Toddler A talking to Toddler B, etc.. The teacher is the client. The toddlers are the objects in the chain. The problem here is that any changes in these relationships require changes in the client.

The fix: Refactor by hide delegate.


Data Clumps

This is when different parts of the code contain the same groups of variables. One classic example is when you find parameters to connect to services multiple times in the code.

The fix: Refactor by creating a new parameter object or extracting the class.


Poltergeists

These are classes with limited roles to play in the system, essentially just cluttering up the software. They can be transient associations, stateless classes, temporary objects and classes, and redundant navigations.

The fix: Refactor by moving actions that were originally inside the poltergeist into the related classes that they invoke.


Conclusion

Now that I’ve detailed 15 different ways to spot that bad code, it’s time to end on a good note by defining good code.

@safesolvent unsplash.com
  • Good code is well-organized, well-tested, simple, and straightforward.
  • Good code is so elegant that you can easily explain the logic to your school-age children.
  • The story of good code can be told by anyone. Your programmers don’t have to be rocket scientists to write good code.
  • Most importantly, good code will live on.

If you haven’t read the book “Clean Code: A Handbook of Agile Software Craftsmanship,” you probably should.

Good code is just a few simple fixes away. What are you waiting for?


About the Author

Jun Wu is a Content Writer for Technology, AI, Data Science, Psychology, and Parenting. She has a background in programming and statistics. On her spare time, she writes poetry and blogs on her website.

Subscribe to my weekly newsletter to stay connected

Better Programming

Advice for programmers.

Thanks to Zack Shapiro

Jun Wu

Written by

Jun Wu

Single Mom Writer, Technologist, Poet: Tech, AI, Data Science, Leadership, Psych, Parenting, Edu, Life, Work,Poetry etc. Find Me: https://junwuwriter.com

Better Programming

Advice for programmers.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade