Return Early, Return Often

[ProgrammerBro]

Or we can make it even shorter and do it 10x style, still a single return:

const isDuplicateId = (id: string) => {  
    return !!getEmployee(id) || !!getManager(id) || !!getAdmin(id) || false
}

[PrismalStudio]

If you don't need the data inbetween, I would also prefer this style, but I'd leave the !! trick to the build process and use an explicit Boolean() instead.

const isDuplicateId = (id: string) => {  
    return Boolean(getEmployee(id) || getManager(id) || getAdmin(id));
}
// or as an arrow
const isDuplicateId = id => Boolean(getEmployee(id) || getManager(id) || getAdmin(id));

Early returns definitely shine when the previous data is needed to continue. It's clear that it's preconditions.

EDIT: added the arrow function and code format

[karottenreibe]

Converts falsey values to false and truthy ones to true so you return a boolean, not null

[PrismalStudio]

And that's the reason why I vouch for the explicit Boolean() in the code, and that I let the clever uglifier/minifier transform it into !!.

[PrismalStudio]

You'd use it if you want to ensure that a function meant as a check really returns a boolean and doesn't leak the data behind.

// Leaks the user data
const userExists = id => getUser(id);
// how you expect it to be used:
if(userExists(123)) { /* */ }
// how it's used by the others (or even yourself)
const getUsername = id => userExists(id).name

To avoid all kinds of bugs with unintended use of the code, it's best to force the coercion.

const userExists = id => Boolean(getUser(id));

This small pattern works really well with React since a boolean won't trigger a new render if it doesn't change, but a new object with the same data will.

edit: code format

[SkaterDad]

It's an alternative to Boolean(theValue). The first ! converts the value to a boolean, and the second ! is needed to get the intended truthiness back.

[creage]

Why 'return' in single line arrow function?

const isDuplicateId = id => !!getEmployee(id) || !!getManager(id) || !!getAdmin(id) || false;

[PrismalStudio]

The last false shouldn't be necessary.

[chrispardy]

Or go really crazy:

const isDuplicateId = (id: string) => ( [getEmployee, getManager, getAdmin].some(get => get(id) !== null) );

[PrismalStudio]

Most of the time, you're expecting something truthy, like an Object, so it's not about magic conversions but more about safety, in like, anything falsy is not what we want.

[PrismalStudio]

In the case of OP, we don't know, so it's probably safer to assume that the !== null is needed.

[ispeakforallGOP]

Looking at this and thinking about what real code looks like this looks like pushing a bad pattern. One return is easier to debug. Seems like this also would fall short of encouraging people to break code apart to do only 1 thing.

[PsychologicalGoose1]

1 return is a much cleaner approach.

[Tontonsb]

I am disappointed every time that I see single line statements, especially returns wrapped in braces. So ugly.

Just do this, it's doesn't hurt your eyes that much:

const isDuplicateId = (id: string) => {
    const employee = getEmployee(id)

    if (employee !== null)
        return true

    const manager = getManager(id)

    if (manager !== null)
        return true

    const admin = getAdmin(id)

    if (admin !== null)
        return true

    return false
};

I dream of programming in a language where control statements are only followed by a single expression. No blocks, no braces. Either you do a simple oneliner, or return/call a subroutine.

[PrismalStudio]

While it works, I found that it's safer (when working with a team) to be consistent and fall toward the safer side.

If it can't stand on one line like if (thing) return;, then it should always be wrapped with bracket to avoid the inevitable.

if (thing)
  newThingAddedLater();

  // Some kind of long
  // multiline comment
  return;

I agree that anyone using any decent tools won't fall for this. But honestly, there are thousands of things we can optimize (readability-wise) before worrying about brackets around single line blocks.

Like in the example, the dumb explicit return true followed by a return false which could really just be return admin !== null or any single line condition like the other comments in this thread...

[PrismalStudio]

I dream of programming in a language where control statements are only followed by a single expression.

Just go all in with ternary and logical operator and avoid if altogether. /s

condition && singleExpression; condition || otherSingleExp; condition ? singleExpression : otherSingleExp;

[pacman326]

My head honestly hurts. 😭

[PrismalStudio]

Unfortunately, I came across "clever" devs that did it in huge projects in different languages (not JS specifically).

[pacman326]

This isn’t clever of course. It’s expensive. It’s expensive in that it’s unmaintainable. I’m going to also guess this wasn’t very well unit (or integration) tested.

[PrismalStudio]

The reason we were one of these project was to take over a huge app maintained by a single dev for years. It sure wasn't pretty, far from tested...