327 reads

How to Find the Stinky Parts of Your Code [Part XXXIII]

by Maximiliano ContieriMarch 24th, 2023

Too Long; Didn't Read

It smells because there are likely many instances where it could be edited or improved. Most of these smells are just hints of something that might be wrong. They are not required to be fixed per se, though. (You should look into it, though.) Previous Code SmellsYou can find all the previous code smells (Part i - XXXII) here.

featured image - How to Find the Stinky Parts of Your Code [Part XXXIII]

‘a skunk smelling code’ Image created by HackerNoon AI Image Generator

It smells because there are likely many instances where it could be edited or improved.

Most of these smells are just hints of something that might be wrong. Therefore, they are not required to be fixed per se… (You should look into it, though.)

Previous Code Smells

You can find all the previous code smells (Part i - XXXII) here.

Let's continue...

Code Smell 161 - Abstract/Final/Undefined Classes

Your classes are abstract, final, or undefined

TL;DR: If your language has the right tool, your classes should be either abstract or final.

Problems

Subclassification for Code Reuse

Classes with just one concrete subclass

Liskov Substitution Violation

Yo-Yo Problem

Solutions

Declare all your leaf classes as final and the rest of them as abstract.

Context

Managing hierarchies and composition is the main task of a good software designer.

Keeping hierarchies healthy is crucial to favor cohesion and avoid coupling.

Sample Code

Wrong

public class Vehicle
{
  // the class is not a leaf. Therefore it should be abstract
    
  // an abstract method that only declares, but does not define the start 
  // functionality because each vehicle uses a different starting mechanism
  abstract void start();
}

public class Car extends Vehicle
{
  // the class is a leaf. Therefore it should be final
}

public class Motorcycle extends Vehicle
{
  // the class is a leaf. Therefore it should be final
}

Right

abstract public class Vehicle
{
  // the class is not a leaf. Therefore it must be abstract  
 
  //an abstract method that only declares, but does not define the start 
  //functionality because each vehicle uses a different starting mechanism
  abstract void start();
}

final public class Car extends Vehicle
{
  // the class is a leaf. Therefore it is final
}

final public class Motorcycle extends Vehicle
{
  // the class is a leaf. Therefore it is final
}

Detection

[x]Automatic

Since this is enforced by static analysis, we can't do it with most available tools.

Conclusion

We should look back at our classes, and start qualifying them either as abstract or final.

There are no valid cases for two concrete classes, one subclassifying the other.

Relations

Code Smell 11 - Subclassification for Code Reuse

Code Smell 136 - Classes With just One Subclass

Code Smell 37 - Protected Attributes

Code Smell 58 - Yo-yo Problem

More Info

Coupling - The one and only software design problem

Deep Subclasses

Disclaimer

Code Smells are just my opinion.

Credits

Photo by William Bossen on Unsplash

When the final design seems too simple for the amount of work you've put in, then you know you're done.

Brady Clark

Code Smell 162 - Too Many Parentheses

Parentheses are free of charge. Aren't they?

TL;DR: Use as few parentheses as possible.

Problems

Readability

Syntactic complexity

Solutions

Remove all not necessary parentheses

Context

We read code from left to right (at least, in western culture).

Parentheses often break this flow, adding cognitive complexity.

Sample Code

Wrong


schwarzschild = ((((2 * GRAVITATION_CONSTANT)) * mass) / ((LIGHT_SPEED ** 2)))

Right


schwarzschild = (2 * GRAVITATION_CONSTANT * mass) / (LIGHT_SPEED ** 2)

Detection

[x]Automatic

This is a fully automated code smell.

It is based on syntax trees.

Many tools detect it.

Exceptions

On some complex formulas, we can add extra parenthesis for terms’ readability.

Relations

Code Smell 02 - Constants and Magic Numbers

Conclusion

We write code once and read it too many times.

Readability is king.

Credits

Photo by Nick Fewings on Unsplash

If someone claims to have the perfect programming language, he is either a fool or a salesman or both.

Bjarne Stroustrup

Code Smell 163 - Collection in Name

Have you ever seen a CustomerCollection?

TL;DR: Don't use 'collection' in your name. It is too abstract for concrete concepts.

Problems

Readability

Abstraction Abuse

Bad Naming

Solutions

Rename the collection with a specific name.

Context

Naming is very important.

We need to deal a lot with collections.

Collections are amazing since they don't need nulls to model the absence.

An empty collection is polymorphic with a full collection.

We avoid nulls and IFs.

We often use bad and vague names instead of looking for good names in the MAPPER.

Sample Code

Wrong


for (var customer in customerCollection) {

    // iterate with current customer

}



for (var currentCustomer in customersCollection) {

    // iterate with current customer

}

Right


for (var customer in customers) {

    // iterate with current customer

}

Detection

[x]Semi-Automatic

All linters can detect a bad naming like this.

It can also lead to false positives, so we must be cautious.

Conclusion

We need to care for all our clean code, variables, classes, and functions.

Accurate names are essential to understand our code.

Relations

Code Smell 134 - Specialized Business Collections

More Info

What exactly is a name - Part II Rehab

Credits

Photo by Mick Haupt on Unsplash

Alzheimer's Law of Programming: Looking at code you wrote more than two weeks ago is like looking at code you are seeing for the first time.

Dan Hurvitz

Code Smell 164 - Mixed Indentations

Tabs vs Spaces. The most significant computer problem.

TL;DR: Don't mix indentation styles

Problems

Readability

Code consistency

Standards violation

Solutions

Choose one of them.
Stick to it.
Enforce it with code standards tests.
Share the rules on all the codebases.
Use an IDE like VSCode or WebStorm that doesn't include tabs at all.

Context

Whenever I publish an article many people don't care about the sample intent and rush to point out indentation mistakes.

Choosing one standard over the other will be a great solution.

Spaces always count as one.

Tabs can count as many different options.

Sample Code

Wrong


function add(x, y) {

// --->..return x + y;



      return x + y;

}



function main() {

// --->var x = 5,

// --->....y = 7;



    var x = 5,

        y = 7;

}

Right


function add(x, y) {

// --->return x + y;

    return x + y;

}

Detection

[x]Automatic

Any parser can enforce this rule.

Exceptions

Some languages like Python consider indent as part of the syntax.

In these languages, indentation is not accidental since it changes code semantics.

Conclusion

There's been so much debate on this subject.

The smell is related to mixing them, not about using one instead of another.

Some IDEs automatically convert one convention to the other one.

Relations

Code Smell 48 - Code Without Standards

More Info

ES Lint

Whatever the device you use for getting your information out, it should be the same information.

Tim Berners-Lee

Code Smell 165 - Empty Exception Blocks

On Error resume next was the first thing I learned in my first job.

TL;DR: Don't avoid exceptions. Handle Them.

Problems

Fail Fast Principle Violation

Solutions

Catch the exception, and deal with it explicitly.

Context

In the early programming days, we privileged the systems running before error handling.

We have evolved.

Sample Code

Wrong


# bad

import logging



def send_email(): 

  print("Sending email") 

  raise ConnectionError("Oops")

  

try:

  send_email() 

except: 

  # AVOID THIS

pass

Right


import logging



logger logging.getLogger(__name___)

try:

  send_email()

except ConnectionError as exc:

  logger.error(f"Cannot send email {exc}")