The Boy Scout Rule in Coding

The Boy Scout Rule is the simple rule that can solve a huge problem of software development within a team.

It states: "Always leave the campground cleaner than you found it". Sounds pretty simple, right?

But, despite its' simplicity, not every developer follows this rule (me neither sometimes).

Sometimes, it's just kinda hard to take responsibility for someone else's code. I tell myself: "If someone else made that mess, why I should even work with it?".

But undoubtedly, it's way better for everyone to take care of the code you working on with a team. All the same, we are programming in the high-level languages and those were made for people who work with machines, not the machines themselves.

What is clean code?

To keep the code clean you obviously should know what clean code is and what it takes to write one.

Let's formulate some qualities of the clean code.

1. Clean code is focused.

You don't want your methods to consist of various blocks of unrelated code. You want one particular method to do one particular thing.

First of all, it's easier to remember what the method does and if it has a good name (which is a quality of clean code too) then the user of this method don't even need to know what it does behind the scenes, he can use it out of the box.

But you can say, what if my method should do many things behind the scenes? The key to handling this problem is an abstraction. 

For example, take the Glide library which I discussed in one of my posts Image Loading With Glide. To load an image you should handle HTTP connection, media decoding, memory and disk caching etc. But Glide makes it look like one thing, loading an image.

2. Clean code is expressive

I already talked about it when mentioned that method should have a good name.

Good naming can make your code self-documenting and make documentation less important and in some cases even redundant.

Let's think of a simple example.

  int method(int[] array) {
    if (array == null || array.length < 0)
      return 0;

    int integer = array[0];
    for (int number : array)
      if (number < integer)
        integer = number;
    return integer;
  }

It's pretty easy to determine what this code does, but it would be even easier if we choose better names for the method and variables.

  int min(int[] numbers) {
    if (numbers == null || numbers.length < 0)
      return 0;

    int currentMin = numbers[0];
    for (int candidate : numbers)
      if (candidate < currentMin)
        currentMin = candidate;
    return currentMin;
  }

I just changed the names, nothing else, it does the same thing (and now even the name implies that it searching the minimum in the array). But now it looks much much better.

To be honest, when I was writing the example of bad naming, I made a mistake. I wrote `number > integer instead of `number < integer` and noticed it only when I changed the names. In such a simple procedure, such a huge mistake just because of bad naming. Imagine what can happen when you work on a huge system!

3. Clean Code is minimalistic

Some studies say that it's better to keep your classes and procedures small. 

For classes, there is a magical number that states how many public methods it should have this number is 7. 7 public methods per class makes it easy to remember all the responsibilities of the class. But it doesn't mean, of course, that every class should have only 7 methods, just keep this number close to it.

For methods, there is no concrete number. Robert "Uncle Bob" Martin in his book "Clean Code" says

The first rule of fucntions is that they should be small. The second rule of functions is that they should be smaller than that. Functions should not be 100 lines long. Funcions should hardly ever be 20 lines long. 

While Steve McConnell in "Code Complete" says the following

The routine should be allowed to grow organically up to 100-200 lines, decades of evidence say that routines of such length no bore error prone than shorter routines.

Some people (including Steve McConnel) say that a method should fit the screen without scrolling which is, in my opinion, is the good estimate, despite the fact that everyone has different screens.

I personally think that you should break down the method as soon as you find yourself trying to remember what does some part of the method do. Probably, when someone will look at this part he won't understand it, so it's better to replace it with well-named procedure.

These are in my opinion are top 3 qualities of clean code. There are more of course and you can find all of them in already mentioned books: Code Complete by Steve McConnell and Clean Code by Robert C. Martin.

Now when you know what clean code is you can start following The Boy Scout Rule of coding and make your and your co-workers' live easier. Sometimes it would be easy as renaming some variables. Sometimes it would require changes in the architecture of the software but it always worth it because you are the one who will work with this code.

Now let's make our code a better place! Maybe there is a badge for it ;)