The Boy Scouting Rule

The Boy Scouts of America learn a really simple rule, which says:

We can take this rule and adapt it into programming too. In Fact Robert C. Martin already did this in his famous book Clean Code:

If we continuously improve code as soon as we see optimization potential, then code quality will automatically increase, without even really recognising the effort.

With this in mind, let's head to some examples.

Boy Scout Rule in Action#

No matter how much code lines will be changed, each cleanup counts and therefore matters.

Example 1: Change Names#

One of the easiest refactor is changing names, because it can be mainly made with the help of the IDE, let's look at following example:

double[] values = new double[]{10.0, 6.0, 2.0, 15.0};
// some calculation ...

We have a pretty generic name value right here, which says nothing about the semantics. Let's assume the values are captured speed from bicycles, so why not name it like this:

double[] capturedBicycleSpeeds = new double[]{10.0, 6.0, 2.0, 15.0};
// some calculation ...

With this change even a colleague knows what these values actually mean.

Example 2: Comments#

As we learned from a previous post about comments, we know that they eventually lie to us, like in the following code snippet:

double[] capturedBicycleSpeeds = new double[]{10.0, 6.0, 2.0, 15.0};
// calculate median of values
double arithmeticMean = Arrays.stream(capturedBicycleSpeeds).reduce(Double::sum).getAsDouble() / capturedBicycleSpeeds.length;

The comment states, that it calculate the median of the given array. If we look closely we see, that this is not the case here, because it calculates the arithmetic mean, so we should change the comment. Even better in my opinion, we could also extract a method out of it and make the comment uneccessary:

double[] capturedBicycleSpeeds = new double[]{10.0, 6.0, 2.0, 15.0};
double arithmeticMean = calculateArithmeticMean(capturedBicycleSpeeds);

private static double calculateArithmeticMean(double[] series) {
    return Arrays.stream(series).reduce(Double::sum).getAsDouble() / series.length;
}


### Example 3: Applying a Principle

Of course refactorings can be more complex, but we should not hesitate to implement them too.
Let's assume we have have a class, which uses a MongoDB connection to store products in MongoDB. This could look like this:

```java
public class MongoDbProductGateway {
    public MongoDbProductGateway(String host, int port) {
        MongoClient client = new MongoClient(host, port);
        database = client.getDatabase("main");
        collection = database.getCollection(PRODUCT_COLLECTION);
    }
}

The snippets shows the initialization of a connection with MongoDB, it also tries to load a collection from this connection. At the same time we have a class that also uses a MongoDB connection to store Customers into a collection:

public class MongoDbCustomerGateway {
    public MongoDbCustomerGateway(String host, int port) {
        MongoClient client = new MongoClient(host, port);
        database = client.getDatabase("main");
        collection = database.getCollection(CUSTOMER_COLLECTION);
    }
}

If you look at the code you may see the duplication in initializing the database connection and creating a new client. So why not apply the DRY Principle here and therefore adhere the boy scout rule:

public abstract class MongoDBConnection {
    private final MongoDatabase database;

    public MongoDBConnection(String host, int port) {
        MongoClient client = new MongoClient(host, port);
        database = client.getDatabase("main");
    }
}

Now both classes can inherit from the abstract class in and remove the duplicate lines of code.

Summary#

With this post, I wanted to share the boy scouting rule with you. If you stumble upon a code snippet that needs improvement, you might remember this post and do a little or big refactoring. I also want to encourage you that even small changes improve the code base of an application and have an impact on code quality.

Thank you for reading!