Filtering visible map layers based on multiple conditions
Okay, so here is how I decided (yes we can say a lot of things about 20 little lines):

Performance


The first code (with a few if) is probably
the best, since the || operator stops whenever a condition is
evaluated to true.
The second one (with the big switch) is a very lil bit slower,
since we compute minRes, maxRes and curRes before evaluating
the first exit conditions where they are unused.
Otherwise, the switch statement stops whenever a truthy case is found.
The third one (with the Array) is the most wrong approach if I want
speed. We compute the variables, store the N conditions in an array
of size N, so they're all evaluated, and then we loop through said array
(.some() method) to tell whether it contains a truthy value.


However, regarding this specific app I'm working on, code legibility
and future features are more important than a few microseconds.

Legibility

My problem here is that legibility is kinda subjective.
I follow specific coding style and guidelines, and it's easier for me
to read code which follows these guidelines that code which doesn't.

Sadly, on this project, there are no defined conventions and there's an
interesting diversity of whitespace habits.


The first code is the most legible for most people coming from C,
but anyone who would come after me would be very tempted to write nested
if, since there are loads of nested code in the repo.
The second one is still quite legible for C pals, and honestly
the individual comments on each condition are nice. Also I believe it is
less tempting to nest conditions, since we would have to change the
structure first.
The last one is the most "eye-candy": it has the advantages of the
switch, while being less heavy (case, break). However, it is
trickier: "What on Earth is this !hideOn.some(Boolean) thing?
Damn, I'll have to check the docs."


Actually, reading the doc is nice I think. Learning about .some()
does not take long, and it's better if maintainers make sure they
know some of the language before, well, maintaining.

Extensibility

Extensibility is also important to me. I know this code will not be
reviewed now, but in a few months someone will probably ask:
"what if we also check this and that?".

In fact, what's likely to happen is "what if we make these conditions
conditional?", ie, add a parameter somewhere, and if this parameter has
some value, then we'll do some more things. This is an interesting way to
check extensibility. Now I'll insert some code since there's been too much
text.

// First code with ifs; nice but we end up nesting conditions
if (configuration === 'wow') {
    doSomething();
    // Comment both conditions
    if (newCond1 || newCond2) {
        return false;
    }
} // Continue

// Second code with switch; I had higher expectations for you
switch () {
case configuration === 'wow':
    doSomething();
    // Comment both conditions
    if (newCond1 || newCond2) {
        return false;
    }
     // Non-breaking case!!
case ...
}

// Other possibility; we may end up with very long lines,
// or multiline conditions (I limit my lines at 80 chars)
switch () {
case configuration === 'wow':
    doSomething();
    // Non-breaking case!!
case configuration === 'wow' &amp;&amp; newCond1:  // Comment condition 1
case configuration === 'wow' &amp;&amp; newCond2:  // Comment condition 2
case ...
}

// Last code with Array; free candy
if (configuration === 'wow') {
    doSomething();
    hideOn.concat([
        newCond1,  // Comment condition 1
        newCond2   // Comment condition 2
    ]);
}


In this particular situation, I think the last one is the most elegant.
Given it's also the most legible in my opinion, and that I'm clearly biased,
and that I want maintainers to read at least ES5 docs once in a while, my choice has been to use the third versions, with the array of booleans.