Clear examples for code smells

Question

does anybody know how the code smells "rigidity", "fragility", "immobility" and "viscosity" can be explained in short code examples?

I've found a lot of text but never a source code example.

Thanks for your hints.

Are there at least very pratical examples, like the following - rigidity: "if the access permission is check at 100 code locations with an SQL statement". The resulting software has a high rigidity because the table for user permissions cannot be changed easily.

//UserInterface.java
// Check permission database
stmt.executeQuery("SELECT * FROM permission WHERE user=‘1’)

//AdminInterface.java   
// Check permission database
stmt.executeQuery("SELECT * FROM permission WHERE user=‘1’)

see Why do 'some examples' and 'list of things' questions get closed? — gnat, Sep 10 '17 at 14:42

score 4 · Accepted Answer · answered Sep 10 '17 at 14:52

Rigidity

The characteristic which makes the code difficult to change, where a small change in one part of the code leads to cascading changes in other parts.

There could be no short code example, since rigidity cannot exist in a small piece of code where there is nothing to cascade.

Your practical example with a SQL query repeated one hundred times through the code is not a sign of rigidity. It's simple code duplication, which, while indicative of poorly written code, doesn't make the maintenance overly complicated. Any IDE will let you find-replace text in all files in a folder, making a change in the query extremely simple—the opposite of what you claimed.

Imagine a different example. Originally, the permissions check was done through a query:

SELECT * FROM permission WHERE user=‘1’

The new requirements is to do it like this:

SELECT * FROM permission WHERE user=‘1’ AND isDisabled=`false`

Exploring the code, it appears that the SQL query is built through a custom-made builder which supports the notion of user ID, but was never designed to handle isDisabled. You start by changing this, and discover that the builder uses a type conversion utility which handles strings and numbers, but not booleans. You add such support, but running the unit tests indicate that you've broken some other part of the code. You fix it, get back to the original assignment, and discover that in order to make it work, you need to change three other classes (and their respective tests), and now that the signature of one of the methods have changed, it requires you to modify ten more classes. Because of the rigidity, instead of doing one change in code and one change in tests, you affected half of the code base.

Fragility

class Probe
{
    static bool finished;

    public void Process()
    {
        while (true)
        {
            var measurement = this.ReadNext();
            if (measurement == null)
            {
                Probe.finished = true;
                break;
            }

            var results = this.Analyze(measurement);
            if (results.Relevant)
            {
                this.S3File.Append(results);
            }
        }
    }
}


// Somewhere else in the code, `Process` is called asynchronously.
// In parallel, the following code is executed every two seconds:
if (Probe.finished)
{
    // Alert the user that the probe finished sending the data.
}

Aside from the improper use of a static field, the major problem is that the field was made public and is accessed from the outside. Checking that the probe finished its measurements in this way makes the code particularly fragile; a change in the internals of the Probe class may break the code.

It would be much better to make the field private (and non-static) and let the caller of Process call this method synchronously and handle the termination of the method accordingly.

Immobility

While the previous piece of code may look like an example of immobility, the smell rather applies to larger blocks of code, and so, there could be no short code example for it.

You recognize it when you ask developers “could we add this simple feature to our booking system?” and they start avoiding eye contact and the most courageous of them scream “Not the booking system! Please, let us avoid what happened two years ago! I can't work once more sixteen hours per day for three weeks to restore all our business critical systems!”

Viscosity

// It would be too complex to use our Dependency Injection framework here, so 
// let's create new instances directly for now. It makes it impossible to run unit
// tests for this class, so beware of regressions.
// TODO: Use Dependency Injection and add unit tests.
...

Clear examples for code smells

1 Answers1

Rigidity

Fragility

Immobility

Viscosity