Human Readable JavaScript

Love the point free (tacit programming) put in there. I am getting more into functional programming but have to consider my peers and juniors coming in when writing my code... Usually, I ask myself "could I have understood or figured this out when I first finished my coding Bootcamp...? If no I refactor."

The refactor from

const arr = [1,2,3]

const timesTwo = (el) => el*2

let multipliedByTwo = arr.map((el) => timesTwo(el))

to

const arr = [1,2,3]

const timesTwoPlusIndex = (el, index) => (el*2) + index

let multipliedByTwo = arr.map(timesTwoPlusIndex)

is one of my favourites.

Interestingly (well, interesting to me anyway), it's an example of η-conversion (eta-conversion), one of the three basic reduction steps in the Lambda calculus.

Love this Laurie!

I'm a .NET developer, but always make it my aim to make code read like a story. Things like

var settings = new Settings(this.Configuration)

vs

var settings = Settings.LoadFrom(this.Configuration)

Simple example, but making your code read like a story makes it so much easier to pick up coming back to it.

I think short functions and readable code are fundamentals for code that others can pick up.

I think it's important not to simplify the code at a point where you avoid using functionalities which are useful but less readable for a newbie.

For example instead of the following:

    let multipliedByTwo = arr.map(
        (el) => { 
            if(el%2 === 0) {
            return el*2
        } else {
            return el+1
        }
    })

I would prefer using ternary, and no optional syntax characters such as parenthesis or curly braces:

let multipliedByTwo = arr.map(el => el % 2 === 0 ? el * 2 : el + 1)

It may seem less approachable for someone who is not used to ternay, arrow functions and the absence of unnecessary syntax characters, but when used to it, it's actually better to have such a one line operation rather than 8 line of basic if...else.

In other words, I prefer to write a code that requires the maintainer to raise his level of JavaScript understanding but enables code to be shorter, rather than making super simple but verbose JavaScript (I hate to search for bits of code in hundred-lines-long files).

How about splitting things up?

timesTwo = e => e * 2;
add = (a, b) => a + b;

const result = arr
.map(timesTwo)
.map(add) // add index

putting maps on separate lines helps people see it broken in to steps

adding in a comment on the "add" helps because most maps don't usually use index.

you could do .map(addIndex) but I don't like this as the original function can add any two things, not just index

or .map((a, i) => add(a, i)) but that creates another function

Hi Laurie, great question.

I don't have a 'one-shoe-fits-all' approach to writing the most readable code all the time. At one point I wished for that, but I'm understanding writing code is better off not that way.

The last pattern described particularly useful when the associated callback function for array.map is so long, I forget that it's a callback. In that case I may have something like this:

// Either import it or placed elsewhere in the same file if not used anywhere else
import {crazyLongCallback} from './crazyCallbacks'

const bigDataList = [...]
const parsedDataList = bigDataList.map(crazyLongCallback) 

So I find it useful when discovering different design patterns and ways to handle problems. I tend to gravitate toward the solution in which I hope me I and my colleagues can read after a day, week, or month's time.

Thanks for the read!

As it turns out, this is again non-optional if our function logic is more than one line.

I know this isn't at all what you meant, but I thought I'd throw this in the comments for fun.

You can many times write code that would normally need curly braces without them by using parentheses expressions. You can't use statements (like creating new variables or if, else, for, etc), but you can call a few functions and return the last value.

const newArr = myArr.map(x => (console.log(x), changeX(x));

Just a little tidbit I thought I'd throw in. Excellent article nevertheless!

What a lovely article you've written! Thank you for putting it down in such easy to read and understand text and idea.

I have noticed the same pattern in my coding style over the last 10 years which you describe here, i.e. I truly tend to write for the next human who will read it (which is mostly myself again) later. And again, it might be someone else! Which means somehow this should be like a moral and professional imperative. I. Kant "the programmer" would like that I guess. :-) Or, as Ezell puts it in the comments before, nicely; "A junior dev would be stressed out trying to read it". It is the thing that we are always the junior dev when you meet some new codebase or logic. Isn't it?

I guess it is more up to the "wits" or "IQ" who gets the idea behind some code faster, and on the contrary the common to all of us is "the codebase" and its style. Why not agree on human readable code first then? So from that point it would be lovely if all tend to write human readable code first. Firstly to help ourselves, to be able to even optimize it to next performance level if needed later. A good test for anyone who doubts this is just open any to your grade complex (non-functional language) codebase on github and try figure out the logic in next 5 minutes. You won't in its totality. How ever hard you try there are hidden non-functional style friendly outside mutations and side-effects that you will not grasp from that single e.g. method or function. I am not praising the functional style here as the holy savior, but trying to figure it out a bit e.g. made a better OOP C# developer in terms of sharing my code with others. Again, never take this (or other forum discussion :p) literally as I'd always go with team compromise and policy and in this case with a named function in place of an anonymous one (an that is in cases where the logic spans further then an operation between two operands like a + b).

I always suggest devs I work with where there is smoke in code there will be fire later, let's rewrite or refactor, step by step of course.

Honestly and acording to my experience:
Better less lines and one comentary line than a lot of curly braces and separates functions.
And second rule:
If a function is more than 10 lines, you should do two.
That is my opinion. Like an ass, everybody has one.

Very nice article and I love the conclusion "There is no one size fits all syntax". I probably would have written the first now version because I like the "functional programming"-mindset it applies.

For people who struggle with arrow functions I would have included the plain "function" version, too:

const arr = [1,2,3]
let multipliedByTwo = arr.map(function(el) {
    return el*2;
})

I had a pretty hard time in grasping lambdas when they were introduced in Java 8 and it was really irking me that most of the tutorials about this topic did not include a 1:1 non-lambda "translation" :/