@wallhackio @aescling Do they?

switch (some_enum) {
case VALUE1:
  do_something();
  break;
case VALUE2:
  do_something_else();
  break;
}

vs.

if (some-enum == VALUE1) {
  do_something();
} else if (some_enum == VALUE2) {
  do_something_else();
}

That's the same amount of indentation...

@vaporeon_ @aescling oh I have a skill issue it seems

@wallhackio @aescling To be fair, Vim's autoindentation keeps trying to do this:

switch (some_enum) {
  case VALUE1:
    do_something();
    break;
  /* and so on */
}

But that's worse IMO, since logically there should be only one indentation and not two

@vaporeon_ @aescling I would always do it like

switch(gorp) {
  case 'norp':
    console.log('norp');
    break;
  case 'sorp':
    console.log('sorp');
    break;
  default:
    console.log(' what the gorp???');
    break;
}

@wallhackio @aescling Cursed
Will not work in C

@vaporeon_ @aescling this is JavaScript

@wallhackio @aescling You can switch statement on a string in JavaScripts? Even though gorp and 'norp' don't point to the same address?

@wallhackio @aescling In other words, JavaScript switch statements do strcmp(gorp, "norp") == 0 for you???

@vaporeon_ @aescling strings are primitives in JS 🔍 ​

@wallhackio @vaporeon_ the equality check on strings in most languages with a string type is an implicit strcmp, yeah. python does this

@vaporeon_ @wallhackio you wanna see some real fucked up shit? switch (true):

  // the navbar links to every chunk of the gallery.
  // the current page does not get a link.
  // index 0 links to `/`.
  /** @type {Node[]} */
  const linksByIndex = [];
  for (let i = 0; i < chunkedImages.length; i++) {
    switch (true) {
      case i === chunkIndex:
        linksByIndex.push(li({ class: "active" }, `${i + 1}`));
        break;
      case i === 0:
        linksByIndex.push(li({}, a({ href: "/" }, `${i + 1}`)));
        break;
      default:
        linksByIndex.push(li({}, a({ href: `/${i + 1}.html` }, `${i + 1}`)));
    }
  }

@aescling @wallhackio Nooooooooooooooooooooooo

Just use an if statement at that point...

@aescling @wallhackio Seriously, why would you write this? I'd just write if (i === chunkIndex), else if (!i), and else...

@vaporeon_ @wallhackio i just irrationally hate if /else if /... that much

@aescling @wallhackio Reported

@vaporeon_ @aescling I with vaporeon on this, I'm going to ask our admin to ban you

@wallhackio @vaporeon_ banning the syscatmin… sure that would go down well :P

@aescling @vaporeon_ I'm sure our elastic search can't break any more often than it already does

@wallhackio @vaporeon_

@aescling @vaporeon_ clearly propaganda

@wallhackio @vaporeon_ when was the last time you actually had to complain to me that it was broken

@aescling @vaporeon_ I was hoping I could say "right now" but unfortunately it is currently functional

@aescling @vaporeon_ I guess I understand the undergrads now because the i++ just made my eye twitch even though it literally doesn't matter

@wallhackio @aescling ??? What's wrong with i++?

@vaporeon_ @aescling
It's "more performant" to use ++i*

^{*It really doesn't matter and even if this does give a teeny, marginal performance boost it's the kind of thing a modern compiler will catch for you anyway}

@wallhackio @aescling If I remember correctly, in one of our courses we were told that this is something that a compiler can easily optimise

@vaporeon_ @aescling yea i agree

@wallhackio @aescling I was agreeing with you, I was saying "we were taught the same thing"

@vaporeon_ @aescling ah I see

@wallhackio @vaporeon_ @aescling you should instead do

switch (gorp) {
case 'norp': {
console.log('norp')
break
}
// etc
}

@Lady @wallhackio @aescling Why are you removing the semicolons?

@vaporeon_ @Lady @wallhackio they’re optional in javascript :3

@vaporeon_ @Lady @aescling JavaScript will auto insert semicolons if you don't add them

There are camps on whether or not you should manually add them

I think ignoring them makes more sense but it was a style convention at my old job to use them and the Deno autoformatter inserts semicolons so I just write them now out of habit

@wallhackio @Lady @aescling Just when I thought you couldn't make me hate JavaScripts even more
Cursed language

@vaporeon_ @wallhackio @aescling wait until you learn about Python

@Lady @vaporeon_ @aescling I only do that if I start declaring variables in the switchies

@wallhackio @vaporeon_ @aescling reasonable but then if you add a variable declaration you have to reindent the whole block so

@wallhackio @vaporeon_ @aescling really one should just not use switch statements unless you are writing Swift which actually does them well

@wallhackio @vaporeon_ hey @aescling how do you feel about

switch (false) {
case !cond1:
// …
case !cond2:
// …
}

you hater of elif

@Lady @wallhackio @vaporeon_ ftr i didn't actually end up thinking switch (true) was better and wouldn’t do it again because it’s just about equally as terrible as that

@aescling @wallhackio @vaporeon_ coffeescript allows a bare switch without a condition statement which effectively compiles to switch (true)

@Lady @wallhackio @vaporeon_ …interesting

@aescling @wallhackio @vaporeon_ coffeescript is good and fun but you have to install node to use it so it’s impossible to say whether it is worthwhile or not

@wallhackio @aescling In some languages (i.e. Ruby), cases are basically syntactic sugar for if/elses anyway. I do appreciate it generally making it easier to see "we're going to do a bunch of comparisons against one thing" though rather than needing to reverify predicates each time.

@aschmitz @aescling I like switch statements I just don't understand why undergrad cs students seem to think they're the pinnacle of software design

Everyone used else if at my old job and it was fine.