A Decalogue for the Extreme Functional Developer
Tags: functional, programming, declarativeprogramming, javascript
Published: 2020-05-25 16:43:30

---
title: A Decalogue for the Extreme Functional Developer
published: true
description: Ten rules that guides you to become an extreme functional developer
tags: functional programming, programming, declarative programming, javascript
cover_image: https://miro.medium.com/max/1400/1*tQGRp6AAMNts0ZeMTBQ1cA.jpeg
---

So, you’ve heard about functional programming. And you’ve heard that it a  good and right thing. But you’re afraid to learn new programming  languages and [all that new weird stuff with strange names](https://github.com/hemanth/functional-programming-jargon).

Be aware that functional programming is not a programming language. It’s a programming paradigm, a programming mindset. It is based on one  fundamental principle:

**A program is a mathematical function.**

I hope you already know what a [mathematical function](https://en.wikipedia.org/wiki/Function_(mathematics)) is:

> A binary relation over two sets that associates every element of the first set with **exactly** one element of the second set.

Once you’ve understood how functions work in Maths, nothing can stop you  anymore to apply the functional paradigm to your daily programming.

But if you still have issues in practicing the functional mindset, then  follow these commandments, and your application will be free from evil.

# **I — Thou shalt not have side effects**

Side effects are the evil in functional programming. Actually, they are the  evil in any programming paradigm. They represent the uncontrollable: you take one action, and other actions are triggered without your explicit  consent.

If you define the function *sum(x, y)*, you expect that it returns the sum of *x* and *y*. You don’t expect that it also does something else, like, for example,  updating a database or incrementing a global variable. If that function  does something else and you don’t know what, there’s a good chance your  program is getting out of control. You may not be able to predict the  result of your desired computation.

The sum of different side effects will eventually generate chaos.

# **II — Remember that every function is a pure function**

Mathematical functions are [pure](https://en.wikipedia.org/wiki/Pure_function). That means they have the following properties:

- For a given set of arguments, the function **always** returns the same result.
- The function has no side effects.

In other words, the output of a function is predictable, and you get exactly and only the result you requested.

# **III — Functions without parameters make no sense**

As per definition, a function is a binary relation. If your function has  no parameters, you are not defining any relation; you are not defining  any function. So, never accept functions as the following in your  codebase:

```javascript
function giveMeANumber() {
  return Math.floor(Math.random() * 100);
}
```

# **IV — Functions without output make no sense**

Once again, if your function has no output or returns *void*, you are not defining a binary relation. You are not defining a  function. So, never accept functions as the following in your codebase:

```javascript
function doSomething() {
  console.log("I've done something!");
}
```

# **V — Functions always returning the same value are actually constants**

Consider the following function:

```javascript
function getPi() {
  return Math.PI;
}
```

Why should you use a function instead of using *Math.PI* directly?

Nothing else to add.

# **VI — Thou shalt not change your function’s parameters**

The parameters of your function are sacred. You don’t have to touch them. If you change them, you are committing a side effect.

Consider the following function:

```javascript
function normalizeFullName(person) {
  person.fullName = `${person.firstname} ${person.lastname}`;
  
  return person;
}
```

This function is changing the *person* parameter. And this is a bad thing! It is a side effect. And this function is not pure.

If you want your function to remain pure (and you should), don’t touch its parameters. They are immutable. The previous function should be  rewritten as follows:

```javascript
function normalizeFullName(person) {
  let myPerson = Object.assign({}, person);
  
  myPerson.fullName = `${myPerson.firstname} ${myPerson.lastname}`;
  
  return myPerson;
}
```

------

# **VII — Thou shalt replace *if* statements with ternary operators or functions**

You use the *if* statement very often, and you don’t see anything wrong with it. Take a look at this function:

```javascript
function getTheLongestString(x, y) {
  let theLongestString;
  
  if (x.length < y.length) {
    theLongestString= y;
  } else {
    theLongestString= x;
  }
  
  return theLongestString;
}
```

Look carefully at your *if*. It is committing a side effect! It is changing a variable that is outside its scope.

You may say: “*It’s not that bad. After all, it is a local variable, a variable declared within the function*”. If you’re going to get a functional mindset, you can’t let it go. If  you want to become an extreme functional developer, you should use a  functional approach wherever it is possible.

Use the ternary operator instead of the *if* statement, and rewrite your function as follows:

```javascript
function getTheLongestString(x, y) {
  return ( x.length < y.length ? y : x );
}
```

Your code will be more concise, and you don’t risk commiting side effects.

# **VIII — Thou shalt replace loops with Higher-Order functions**

Even loops are a source of side effects. Consider the following function definition:

```javascript
function getTheLongestStringInAList(stringList) {
  let theLongestString = "";
  
  for (let i=0; i < stringList.length; i++) {
    if (stringList[i].length > theLongestString.length) {
      theLongestString = stringList[i];
    }
  }
  
  return theLongestString;
}
```

Your loop is changing variables, and you might lose control of this soon.  You should avoid loops because of their harmfulness for your code’s  purity. You should use [Higher-Order functions](https://en.wikipedia.org/wiki/Higher-order_function) like *map()*, *filter()*, and *reduce()* (or the equivalent in your favorite language).

Rewrite your function as follows:

```javascript
function getTheLongestStringInAList(stringList) {
  return stringList.reduce(
    (theLongestString, currentString) =>
      currentString.length > theLongestString.length ? 
        currentString
        :
        theLongestString
    ,
    ""
    );
}
```

You can do even better by composing your functions:

```javascript
function getTheLongestStringInAList(stringList) {
  return stringList.reduce(getTheLongestString, "");
}
```

Everything will be easier.

If your language doesn’t support those Higher-Order functions or you don’t understand them, you can use recursion instead of loops:

```javascript
function getTheLongestStringInAList(stringList) {
  let firstString = stringList[0];
  let remainingList = stringList.slice(1);
  
  return remainingList.length === 0 ? 
    firstString
    :
    getTheLongestString(firstString, getTheLongestStringInAList(remainingList));
}
```

Your functional mindset will gain a lot from it.

# **IX — Your variables must be constants**

And since we said that changing parameters and variables is a risk for your functional mindset, why are you still using variables?

If you want to become a fully functional developer, you shouldn’t rely on  variables. Variables don’t have to change. They should be immutable.  They are just placeholders for values. They are constants.

So, rewrite your functions as in the following example:

```javascript
function getTheLongestStringInAList(stringList) {
  const firstString = stringList[0];
  const remainingList = stringList.slice(1);
  
  return remainingList.length === 0 ? 
    firstString
    :
    getTheLongestString(firstString, getTheLongestStringInAList(remainingList));
}
```

Make sure that your programming language has real constants and not just [constant references as in JavaScript](https://ponyfoo.com/articles/const-variables-not-immutable).

# **X — Thou shalt not use variables at all**

If you want to reach an extreme functional mindset, you should totally  give up variables. They are useless. They are obstacles along your way  to the functional perfection: a program is a mathematical expression!

Your function should look like the following:

```javascript
function getTheLongestStringInAList(stringList) {
  return stringList.slice(1).length === 0 ? 
    stringList[0]
    :
    getTheLongestString(
      stringList[0],
      getTheLongestStringInAList(stringList.slice(1))
    );
}
```

Or even better, like so:

```javascript
const getTheLongestStringInAList = (stringList) =>
  stringList.slice(1).length === 0 ? 
    stringList[0] 
    :
    getTheLongestString(stringList[0], getTheLongestStringInAList(stringList.slice(1)));
```

👏 Congratulations! Welcome to [Lisp](https://en.wikipedia.org/wiki/Lisp_(programming_language)).👏

Now, follow this Decalogue, and the functional heaven will be yours. You have no excuse.

*This post was originally published on [my Medium profile](https://medium.com/@andrea.chiarelli/a-decalogue-for-the-extreme-functional-developer-864d84d4104d)*