>Decision Tables

>Instead of hardcoding the logic inside our function, we can place each if-else block in its own function and put those functions in an array, forming a decision table.

In my experience this is always an unwelcome addition to a codebase and a worse choice than just several lines of ifs

* You've added a level of indirection

* You've written the code in a less straightforward way, your fellow programmer might now need to spend more time understanding what they're looking at and wondering why you wrote it like that instead

* The ifs are still there, it's not inherently simpler just because it's tucked away

* They could've been tucked away in functions, which have the benefit of having names, making them (maybe) a bit more self-explanatory?

But most importantly

* You've introduced an abstraction, and it might be the wrong one

What if one of the conditions need to have a different kind of follow up?

Some people then build two separate decision tables depending on what the follow up needs to be, some take the outstanding "if" out of the decision table and add it back in the regular control flow, which kind of highlights the problem on its own, but...

Some other people double down and make the decision table a more robust abstraction, and in my opinion this is the worst outcome. You end up with some bullshit Predicate & PredicateEngine, callbacks, why not maybe async, and at that point you need to look at it and realize "We're making a framework, and we will eventually need to extend it until it encompasses the entire possibilities of the language's control flow, except with massive overhead, and nothing of value being created"

    async function assignDriver(rider, availableDrivers) {
        const driverDistances = await calculateDistances(rider.location, availableDrivers);

        for (let driver of availableDrivers) {
            if (driverDistances[driver.id] > 5) {
                continue;
            }
            if (rider.preferredVehicle && rider.preferredVehicle !== driver.vehicle) {
                continue;
            }
            if (driver.rating < 4.0) {
                continue;
            }
            if (driver.rating >= 4.5 && rider.preferences.includes('Premium Driver') && !driver.isPremiumDriver) {
                continue;
            }
            return driver;
        }

        return null;
    }

Personally I think the most valuable concept is simply naming the internal parts of a larger block of logic. The article does that in the last step, but doesn’t name it in the summary. :P Doing the naming at any step with temporary variables or functions usually makes it cleaner and clearer.

Every article like this presents itself as if one programmer’s bugaboo is a problem for all programmers.

Notice that the author didn’t explain how the nested IF ELSE form worked. That’s because we all know how it works. It’s dirt easy. There is a lot to be said for programming in a way that is familiar and plain.

Yes, there are clever alternatives, but most of them require more time to stare at them and work out what is happening.

the if statements are fine

It needs to be said, "elseif" statement should not exist at all.

I have fixed a lot of bugs due to "elseif" over the decades in various languages. The person who came up with that construct should endure the Confy Chair.

https://www.youtube.com/watch?v=T2ncJ6ciGyM