EDIT: read the article turns out it’s super useful… It gives insight into decision table which is a pattern I did not know about until recently…

Is this really a recurring design pattern for y’all?

I mean, you can just use a switch. anyways I’ll read the article and see ;)

This doesn’t get rid of the if statements. It hides them.

As a Jr Developer, I found this very helpful. Thanks.

I love how this tries to sell making your code strictly worse as something positive.

Sigh. And it’s still full of ifs.

Looks like it’s JavaScript, but in Java I would prefer to use the Stream API, something like this:

return availableDrivers.stream()
    .filter(driver -> calculateDistance(rider, driver) < 5)
    .filter(driver -> isPreferredVehicle(rider, driver))
    .filter(driver -> meetsRiderPreferences(rider, driver))
    .findFirst()
    .orElse(null);

Then we have:

private boolean meetsRiderPreferences(Rider rider, Driver driver) {
    if (driver.rating >= 4.5) {
        if (rider.preferences.includes('Premium Driver')) {
              return driver.isPremiumDriver;
        } else {
              return true;
        }
    } else if (driver.rating >= 4.0) {
        return true;
    } else {
        return false;
    }
}

This increases the separation of concern in a neat way, and it becomes more clear what the for loop does at a glance (get the first driver satisfying a set of conditions). The more complicated logic is isolated in meetsRiderPreferences, which now only returns true or false. Reading the method is more about making a mental map of a truth table.

It’s also easy to expand the logic (add more filter conditions, sort the drivers based on rating and distance, break out meetsRiderPreferences into smaller methods, etc.).

Not sure how the equivalent in JavaScript would look like, but this is what I would do in Java.

private boolean meetsRiderPreferences(Rider rider, Driver driver) {
    if (driver.rating >= 4.5) {
        if (rider.preferences.includes('Premium Driver')) {
              return driver.isPremiumDriver;
        } else {
              return true;
        }
    } else if (driver.rating >= 4.0) {
        return true;
    } else {
        return false;
    }
}

private boolean meetsRiderPreferences(Rider rider, Driver driver) {
    if (driver.rating < 4.0) return false;
    if (driver.rating < 4.5) return true;

    return rider.preferences.includes('Premium Driver') ? driver.isPremiumDriver : true;
}

private boolean meetsRiderPreferences(Rider rider, Driver driver) {
    return driver.rating switch {
        

While I can get behind most of the advice here, I don’t actually like the conditions array. The reason being that each condition function now needs additional conditions to make sure it doesn’t overlap with the other condition functions. This was much more elegantly handled by the else clauses, since adding another condition to the array has now become a puzzle to verify the conditions remain non-overlapping.

My issue with this is that it works well with sample code but not as well with real-world situations where maintaining a state is important. What if rider.preferences was expensive to calculate?

Note that this code will ignore a rider’s preferences if it finds a lower-rated driver before a higher-rated driver.

With that said, I often work on applications where even small improvements in performance are valuable, and that is far from universal in software development. (Generally developer time is much more expensive than CPU time.) I use C++ so I can read this like pseudocode but I’m not familiar with language features that might address my concerns.

Sometimes is it worth to rethink the problem. Especially when your condition is based on set-members. Using quantor logic often simplifies the condition :

return 
    any(x for x in X if x==condition_a) 
    or all(y for y in Y if y==condition_b) 
    and all(x for x in X if x==condition_c)

I am not sure if JS has something similar, but this often helps by a lot

The fact that the loop is doing “find first driver matching these strange criteria” seems most obviously obscured by the pattern of assigning a value, then killing the loop or not. This strikes me as the part that makes the algorithm tedious to test, since it forces us to use a collection to test the intricacies of the inner conditions.

Once we isolate “find first driver matching condition” from computing the condition for each driver, I consider the rest a question of personal taste. Specification pattern, composition of filters, something like that. Whatever you find easier to follow.

This is called the Pyramid of Doom, by the way.