Introduction

Following a couple of simple rules when writing software could be a decision that helps teams write code that applies principles such as the Single Responsibility and Dependency Inversion Principle.

According to Kent Beck a project is Simple if it follows these rules:

1. Create all tests
2. No code duplicity
3. Express the purpose
4. Minimize the number of methods and classes

These rules are in order of reverence and will be reviewed in order.

Rule 1: Create all tests

A software must execute as expected, validation of expected results in software is crucial. Software that can be tested and that passes all test cases can be validated, software that cannot be tested and cannot be validated needs to be refactored to comply with rule 1.

When creating unit tests it is wise to apply the Single Responsibility Principle (SRP), to simplify testing. Therefore, clean tests implies in cleaner code, that results in better systems.

Avoiding abstractions in most cases makes it difficult to create tests. When code is tested it should be refactored to make testing simple and efficient. Having well tested software makes for better projects with loose coupling.

Rule 2: No code duplicity

Code repetition represents unnecessary code that implies in more complexity. In the next example there are code duplication when values are swapped.

Example 1:

public static void SelectionSort(int[] input)
{
    for (var i = 0; i < input.Length; i++)
    {
        var min = i;
        for(var j = i + 1; j < input.Length; j++) { 
            if(input[min] > input[j])
            {
                min = j;
            }
        }

        if(min != i)
        {
            var lowerValue = input[min];
            input[min] = input[i];
            input[i] = lowerValue;
        }
    }
}

public static void BubbleSort(int[] input)
{
    var itemMoved = false;
    do
    {
        itemMoved = false;
        for (int i = 0; i < input.Count() - 1; i++)
        {
            if (input[i] > input[i + 1])
            {
                var lowerValue = input[i + 1];
                input[i + 1] = input[i];
                input[i] = lowerValue;
                itemMoved = true;
            }
        }
    } while (itemMoved);
}

The refactored code eliminates code duplicity and now change to this code is structure to one Swap method:

Example 2:

public static void SelectionSort(int[] input)
{
    for (var i = 0; i < input.Length; i++)
    {
        var min = i;
        for(var j = i + 1; j < input.Length; j++) { 
            if(input[min] > input[j])
            {
                min = j;
            }
        }

        if(min != i)
        {
            Swap(input, min, i);
        }
    }
}

public static void BubbleSort(int[] input)
{
    var itemMoved = false;
    do
    {
        itemMoved = false;
        for (int i = 0; i < input.Count() - 1; i++)
        {
            if (input[i] > input[i + 1])
            {
                Swap(input, i + 1, i);
                itemMoved = true;
            }
        }
    } while (itemMoved);
}

public void Swap(int[] input, int firstPosition, int secondPosition)
{
    var swapValue = input[firstPosition];
    input[firstPosition] = input[secondPosition];
    input[secondPosition] = swapValue;
}

Rule 3: Expressiveness

Writing code that compiles is trivial, but developing software that other humans comprehends can be challenging. High costs in software development are usually a result of software maintenance. To minimize time it takes for others to understand code, a software project must express its purpose clearly.

There are a couple of ways to better express purpose through code as displayed in the following list:

• Good naming conventions for method and classes.
• Small classes and methods that follows SRP.
• Unit tests that express what is being tested and expected result.
• Design patterns naming that one can easily understand its purpose like UnitOfWork instead of UOW.

According to uncle bob the most important rule to follow when writing expressive code is to try. Sometimes software developers want to deliver code fast, but spending a little more time thinking about simple naming convention can make for cleaner code.

Rule 4: Classes and methods

When following the other 3 rules for testing, duplicity and expressiveness, one might think that a new class is necessary for everything.

Creating classes and methods should be something moderated and well planned. The goal of this rule is to create a small overall system while having minimal number of classes and methods. Too many classes and methods can lead to unnecessary complexity depending on the nature of the application.

References

1. Clean Code: A Handbook of Agile Software Craftsmanship by Robert
2. Extreme Programming Explained: Embrace Change by Kent Beck
3. https://dotnetcoretutorials.com/2020/05/10/basic-sorting-algorithms-in-c/