Test-Driven Development in Java/

...

/

Recognizing Bad Code

Recognizing Bad Code

Identify indicators of bad code quality and understand the reasons behind its creation.

We'll cover the following...

Identifying bad code

Now that we’ve seen an example of code that’s difficult to work with, and understood how it came about, let’s turn to the obvious next question: how can we recognize bad code? Admitting that our code is difficult to work with is one thing, but to move past that and write good code, we need to understand why code is bad. Let’s identify the technical issues.

Bad variable names

Good code is self-describing and safe to change. Bad code is not.

Names are the most critical factor in deciding whether code will be easy to work with or not. Good names tell the reader clearly what to expect. Bad names do not. Variables should be named according to what they contain. They should answer:

  • Why would I want to use this data?
  • What will it tell me?
Press + to interact

Data types as names

A string variable that has been named string is badly named. All we know is that it is a string. This does not tell us what’s in the variable or why we would want to use it. If that string represented a surname, then by simply calling it surname, we could’ve helped future readers of our code understand our intentions much better. They would be able to easily see that this variable holds a surname and should not be used for any other purpose.

Language limitations

The two-letter variable names we saw in the listing in the figureUntitledConcept1 represented a limitation of the BASIC language. It was not possible to do better at the time, but as we could see, they were not helpful. It is much harder to understand what sn means than surname, if that’s what the variable stores. To carry that even further, if we decide to hold a surname in a variable named, we have made things really difficult for readers of our code. They now have two problems to solve:

  • They have to reverse-engineer the code to work out that x is used to hold a surname.

  • They have to mentally map x with the concept of surname every time that they use it.

Best practice

It’s so much easier for readers when we use descriptive names for all our data, such as local variables, method parameters, and object fields.

Best practice for naming variables:

  • Describe the data contained, not the data type.

We now have a better idea of how to go about naming variables. Now, let’s look at how to name functions, methods, and classes properly.

Bad function, method, and class names

The names of functions, methods, and classes all follow a similar pattern. In good code, function names tell us why we should call that function. They describe what they’ll do for us as users of that function. The focus is on the outcome—what will have happened by the time the function returns.

Functionality as the function name

We don’t describe how that function is implemented. This is important. It allows ...