I’ve been a developer for over five years, and one of the best things I’ve learned is functional programming. Which gets a lot of hype and can be a bit daunting, but I’ve broken it down into a few simple ideas:

• Returning early and often
• Single purpose functions

These are pretty tightly coupled and inspired by my friends’ posts (which you should definitely check out) about NEVER using ELSE.

Return

Here’s an example in Go. We’ll load some data, do some work on the data, and return the result. Loading data and doing some calculations could both return an error and the actual thing we want.

func main() {
	data, err := loadData()

	result, err := someCalculation(data)

	return result, err
}

Now that code will run fine. However, if there is an error from load data and doing the calculation, we’ll only ever see the second error as it will override the original error.

A nightmare to debug!

Not only that, but we’ll also be doing extra computations we don’t need!

We can fix it by checking for errors and returning that early.

func main() {
 data, err := loadData()

 if err != nil {
  return nil, err
 }

 result, err := someCalculation(data)

 if err != nil {
  return nil, err
 }

 return result, nil
}

This will save us from doing any extra computation unnecessarily and gives us context if any error happens. This second code block could be improved further with proper logging too.

It’ll be much easier to debug when something goes wrong too!

Single purpose functions

Returning early and often also helps lead us to functions with only a single purpose.

Let’s take the following example of some routing in JavaScript. Imagine we’re parsing the URL e.g. /:page Based on the page, import some code. We also could have no page value set if someone goes to just /. We also only want to load the profile code if a user is authenticated.

You can see it’s pretty complex to read and already wrong as it is missing an else, and we’re not returning anything, so it could lead to some mutations.

if (!page || page === 'home') {
  import('./home.js')
} else if (page === 'blog') {
  import('./blog.js')
} else if (page === 'login') {
  import('./login.js')
} 
if (page === 'profile' && isUserAuthenticated) {
  import('./profile.js')
} else {
  import('./lost.js')
}

Let’s break it out into single-purpose functions!

We’ll start by checking if the page is known to us. Then check if the page needs authentication and if the user is logged in. Finally, we’ll import the write code depending on the page.

/**
 * Check if the page is a known page
 * Default to home page if route is just /
 * Otherwise show lost page
 * @param {String} page the page parsed from the url
 * @returns {String} validated page to go to
 */
const validatePage = (page) => {
  if (!page) {
    return 'home'
  }
  if (['profile', 'blog', 'login'].includes(page)) {
    return page
  }
  return 'lost'
}

/**
 * Check if the page is authorised and we have a user logged in
 * Otherwise, they need to login
 * @param {String} page the validated page
 * @param {Boolean} isUserAuthenticated if the user is logged in
 * @returns {String} the page to go to 
 */
const validateAuthorisedPage = (page, isUserAuthenticated) => {
  const authenticatedPages = ['profile']
  if (authenticatedPages.includes(page) && isUserAuthenticated) {
    return page
  }
  return 'login'
}

/**
 * Import the right code for each page
 * @param {String} page to load
 * @returns {Promise} the pending import
 */
const importPage = async (page) => {
  switch (page) {
    case 'home':
      return import('./home.js')
    case 'blog':
      return import('./blog.js')
    case 'profile':
      return import('./profile.js')
    case 'login':
      return import('./login.js')
    default:
      return import('./lost.js')
  }
}

You can see that these are only responsible for doing one thing! It also takes advantage of returning early and often too. This makes it easier to read and understand, and it makes testing a breeze!

Summary

In summary, mutation is the enemy!

Thinking about returning as early as possible helps keep our code simple, leads to easier error handling, and is less likely for side effects to occur!

What do you think? Any other tips for simpler code?

Improving My Code by Returning Early, Returning Often! was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.