Define value boundaries early, keep things flat #best practices #refactoring #code review

POST.md

title	slug	createdAt	language	preview
Define value boundaries early, keep things flat	define-value-boundaries-early-keep-things-flat	2018-11-01T18:45:46Z	en	This is actually one of my personal favourite refactors. It reduces nesting, gives structure for functions and in many cases provides the answer to readers' question quicker.

Why early returns make your code easier to understand

Quite often I come across if statements starting from the very beginning of the function and stretching all the way to the end.

function upload(file) {
  if (file.size < 9999999) {
    const directory = getStorageDirectory()
    
    /*
     * ...
     */
     
    return saveFile(directory + file.name);
  } else {
    throw new Error('File too large')
  }
}

The intention of these if-statements is clear. You want to validate the received input. However, the physical structure of the code used for this constraint is not optimal as it takes over way more area as it should be responsible of. Havng to indent the whole function body because of this is a clear symptom of something being off.

Also, having the start of the structure so far away from the end of it is almost like reading a very long sentence. By the time you get to the end you've already forgotten what was said in the beginning.

This is actually one of my personal favourite refactors. It reduces nesting, gives structure to functions and makes function constraints easier to understand.

From this:

function upload(file) {
  if (file.size < 9999999) {
    if (file.name.length > 5) { 
      if (file.format === 'jpeg') {
        saveFile('jpegs/' + file.name);
      } else {
        saveFile('others/' + file.name);
      }
    }
  }
}

To this:

function upload(file) {
  if (file.size >= 9999999) {
    return;
  }
  
  if (file.name.length <= 5) {
    return;
  }

  if (file.format === 'jpeg') {
    saveFile('jpegs/' + file.name);
    return;
  }
  
  saveFile('others/' + file.name);
}

---

Explanation

1. Always avoid nesting if statements

In most cases it's not actually needed. Oftentimes it's a sign that conditions should be either flipped (take a look at what happens to if (file.size < 9999999)) or combined.

1.1. Define parameter boundaries early, maximise happy code

Notice also that by doing this, we are able to draw a line between dangerous code, where we're unsure about the validity of our parameters and the happy code where we know the input is always valid. Happy code is easier to both read and write and we aim to maximise the amount of it.

1.2. Validate as soon as you can

In this example, we would ideally want to validate the file parameter before it hits this function. That way we could drop the if statements altogether. We could do this for example in the function calling this function. Or even the function calling that one. Ideally we wouldn't have invalid files in our application at all!

👍 As a rule of thumb: Validate user inputted parameters as soon as they reach your code.

function upload(file) {
-   if (file.size < 9999999) {
-     /* 1. */
-     if (file.name.length > 5) { 
-       if (file.format === 'jpeg') {
-         saveFile('jpegs/' + file.name);
-       /* 2. */
-       } else {
-         saveFile('others/' + file.name);
-       }
-     }
+   if (file.size >= 9999999) {
+     return;
+   }
+   
+   if (file.name.length <= 5) { 
+     return
+   }
+   if (file.format === 'jpeg') {
+     saveFile('jpegs/' + file.name);
+   /* 2. */
+   } else {
+     saveFile('others/' + file.name);
  }
}

function upload(file) {
  if (file.size >= 9999999) {
    return;
  }
  
  if (file.name.length <= 5) { 
    return
  }
  if (file.format === 'jpeg') {
    saveFile('jpegs/' + file.name);
  /* 2. */
  } else {
    saveFile('others/' + file.name);
  }
}

2. else is often unnecessary

In this case getting rid of else by returning from the first branch gets rid of 1 level of indentation. Some linters also complain about this, because the code will be unreachable

function upload(file) {
  if (file.size >= 9999999) {
    return;
  }
  
  if (file.name.length <= 5) { 
    return
  }
  
  if (file.format === 'jpeg') {
    saveFile('jpegs/' + file.name);
- } else {
-   saveFile('others/' + file.name);
+   return;
  }
+   
+  saveFile('others/' + file.name);
}

Why I say it's often unnecessary is, that there are cases where it can be argued using else improves readability.

Consider:

if (user) {
  res.send(200)
} else {
  res.send(404)
}

vs

if (user) {
  res.send(200)
  return
} 
res.send(404)

Which one do you prefer? The latter one indeed saves you one indent, but adds a return statement that only has the purpose of stopping the function from running. (credits to @Cadiac for this)