• luciferofastora@feddit.org
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    5 hours ago

    I think that somewhat reflects the “parse, don’t validate” advice I found somewhere. I’ll look for the link and edit if I find it (edit: I did!) but the idea is something like “when a value first enters your code, parse it into a type / struct the rest of your code proceeds to use”. That way, you check “does this make sense as a port number?” exactly once, throw it right back at the source if it doesn’t, put a “yep, this fits” stamp on it if it does and never worry about it again, thus saving repetitive boilerplate code.

    • Ephera@lemmy.ml
      link
      fedilink
      English
      arrow-up
      1
      ·
      3 hours ago

      Ah, yeah, very familiar with that article. 🙃

      It’s definitely part of the reason why I like these really narrow types. But the other big reason is that your internal APIs start to look like this:

      Shape sorter game for babies

      It just makes it almost impossible to pass the wrong value into a parameter. You don’t need to wonder, whether you should pass your port variable into a parameter called bind_port, if you introduced separate types BindPort and RemotePort for them.

      Of course, this is a somewhat extreme example. It’s up to you to decide, whether you’re likely to encounter multiple values of the same type and whether it’s therefore helpful to make it impossible to confuse them.