Does this article need to exist? I assumed anyone writing a nested ternary was intentionally writing shit code
Until JS supports switch expressions, nested ternaries will continue to be the most effective way to write multi-state conditionals.
Also, stop using linting tools that prioritize consistency over human readability, and then complaining that the code they generate is not easily-readable by humans.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/switch - hasnt it had this forever? Or are you refering to something else?
Pretty sure they meant
matchas in pattern matching, notswitchas in switch/case/break.You can see the proposal here: https://github.com/tc39/proposal-pattern-matching
they also said switch
expressions, which indicates they want the switch statement to be settable directly to a variable with whatever the return type of the switch is.Match already returns the value which can be thrown into a variable.
Nah, I meant switch, as that's what it's called in C#-land. See above.
That proposal for matching looks interesting, but not quite the same, no.
Are you sure?
Your C# example:
var output = input switch { null => "Null", 0 => "Zero", > 0 => "Positive", _ => "Negative" };JS proposal for match:
const output = match input { when null: "Null"; when 0: "Zero"; if input > 0: "Positive"; default: "Negative"; }
Yeah, a switch expression is different than a switch statement. I'm not actually sure how many languages actually have them, but in C# its...
var output = input switch { null => "Null", 0 => "Zero", > 0 => "Positive", _ => "Negative" };
Or anywhere for that matter. Have you got nested IF()s in Excel? For crying out loud, pop into VBA and write it up as a custom function like a human being.
Good news Everyone
Excel has a JS API now, so we can get rid of VBA entirely and fill Excel with terrible ternary operators!
Oh, I didn't know that Excel could do JS. I haven't touched it since I got out of the field a decade or so ago.
One of the things I did was quite a bit of Excel consulting and training. I remember the joy of trying to decode massive formula cells, especially when there were nested IF()s. My rule of thumb was that anything with more than three functions in one formula got converted to a custom function, even if it didn't have general utility.
I found that anyone who could construct and understand those massive formulas were generally capable of dealing with the equivalent VBA with a bit of training. Also, it was generally true that if they couldn't handle the relevant VBA, they were in no position to deal with massive formulas anyway.
I'm pretty sure wolves don't really bark. They're all growls and howls. You said you wanted more bike shedding, right?
