←back to thread

498 points azhenley | 6 comments | | HN request time: 0s | source | bottom
Show context
stevage ◴[] No.45768231[source]
In JavaScript, I really like const and have adopted this approach. There are some annoying situations where it doesn't work though, to do with scoping. Particularly:

- if (x) { const y = true } else { const y = false } // y doesn't exist after the block - try { const x = foo } catch (e) { } // x doesn't exist after the try block

replies(4): >>45768310 #>>45768515 #>>45768529 #>>45771225 #
1. NathanaelRea ◴[] No.45768310[source]
You could do an absolutely disgusting IIFE if you need the curly brace spice in your life, instead of a typical JS ternary.

  const y = (() => {
    if (x) {
      return true;
    } else {
      return false;
  })();
replies(2): >>45768491 #>>45768521 #
2. cookiengineer ◴[] No.45768491[source]
Technically you could just use an assignment ternary expression for this:

    const y = (x === true) ? true : false;
I used this kind of style for argument initialization when I was writing JS code, right at the top of my function bodies, due to ES not being able to specify real nullable default values. (and I'm setting apart why I think undefined as a value is pointless legacy).

    Composite.prototype.SetPosition(x, y, z) {

        x = (isNumber(x) && x >= 0 && x <= 1337) ? x : null;
        y = (isNumber(y) && y >= 0 && y <= 1337) ? y : null;
        z = isNumber(z) ? z : null;

        if x !== null && y !== null && z !== null {
            // use clamped values
        }

    }
replies(2): >>45768604 #>>45768832 #
3. stevage ◴[] No.45768521[source]
I love it.
4. NathanaelRea ◴[] No.45768604[source]
I typically only use ternaries for single operations and extract to a function if it's too big. Although they are quite fun in JSX. For your code i'd probably do:

  function SetPosition(x, y, z) {
    if (!(isNumber(x) && isNumber(y) && isNumber(z))) {
      // Default vals
      return;
    }
    x = clamp(x, 0, 1337);
    y = clamp(y, 0, 1337);
    z = z;
  }
replies(1): >>45768626 #
5. cookiengineer ◴[] No.45768626{3}[source]
I always call this the difference of return branch styles. Yours I'd describe as "fast fail" aka return false as quickly as possible (for lack of a better terminology) whereas I personally prefer to have a single return false case at the bottom of my function body, and the other validation errors (e.g. in Go) are usually in the else blocks.

In JS, errors are pretty painful due to try/catch, that's why I would probably these days recommend to use Effect [1] or similar libraries to have a failsafe workflow with error cases.

Errors in general are pretty painful in all languages in my opinion. The only language where I thought "oh this might be nice" was Koka, where it's designed around Effect Types and Handlers [2]

[1] https://effect.website/

[2] https://koka-lang.github.io/koka/doc/index.html

6. fuzzythinker ◴[] No.45768832[source]
nitpick: cleaner w/o ()'s, as '=' is the 2nd lowest operator, after the comma separation operator.