• Kogasa@programming.dev
    link
    fedilink
    arrow-up
    9
    arrow-down
    1
    ·
    2 years ago

    People ITT hating on null coalescing operators need to touch grass. Null coalescing and null conditional (string?.Trim()) are immensely useful and quite readable. One only has to be remotely conscious of edge cases where they can impair readability, which is true of every syntax feature

    • ferralcat@monyet.cc
      link
      fedilink
      arrow-up
      1
      arrow-down
      3
      ·
      2 years ago

      Languages with null in them at all anymore just irk me. It’s 2023. Why are we still giving ourselves footguns.

      • Kogasa@programming.dev
        link
        fedilink
        arrow-up
        1
        ·
        2 years ago

        Because you can turn null into an Option monad with a small amount of syntax sugar and static analysis

          • Feathercrown@lemmy.world
            link
            fedilink
            English
            arrow-up
            1
            ·
            1 year ago

            Oh yeah I forgot, first you have to make a blog post, then a devlog, then review the top 10 best features of JS es6 (9 years after it was released…). Then shitpost on social media network for the other half of the week, and boom! You’re officially a Master Programmer!

      • merthyr1831@lemmy.world
        cake
        link
        fedilink
        arrow-up
        0
        ·
        edit-2
        2 years ago

        Because languages need to be able to handle the very common edge cases where data sources don’t return complete data.

        Adding null coalescing to a null-safe language (like dart) is so much easier to read and infer the risk of handling null than older languages that just panic the moment null is introduced unexpectedly.

        • itslilith@lemmy.blahaj.zone
          link
          fedilink
          arrow-up
          0
          ·
          2 years ago

          For old languages, null coalescing is a great thing for readability. But in general null is a bad concept, and I don’t see a reason why new languages should use it. That, of course, doesn’t change the fact that we need to deal with the nulls we already have.

          • wizardbeard@lemmy.dbzer0.com
            link
            fedilink
            English
            arrow-up
            0
            ·
            2 years ago

            How are we supposed to deal with null values though? It’s an important concept that we can’t eliminate without losing information and context about our data.

            0 and “” (empty string/char) are very often not equivalent to null in my use cases and mean different things than it when I encounter them.

            You could use special arbitrary values to indicate invalid data, but at that point you’re just doing null with extra steps right?

            I’m really lost as to how the concept isn’t neccessary.

            • eeleech@lemm.ee
              link
              fedilink
              arrow-up
              1
              ·
              2 years ago

              One alternative are monadic types like result or maybe, that can contain either a value or an error/no value.

            • dukk@programming.dev
              link
              fedilink
              arrow-up
              1
              ·
              edit-2
              2 years ago

              I’ll point to how many functional languages handle it. You create a type Maybe a, where a can be whatever type you wish. The maybe type can either be Just x or Nothing, where x is a value of type a (usually the result). You can’t access the x value through Maybe: if you want to get the value inside the Maybe, you’ll have to handle both a case where we have a value(Just x) and don’t(Nothing). Alternatively, you could just pass this value through, “assuming” you have a value throughout, and return the result in another Maybe, where you’ll either return the result through a Just or a Nothing. These are just some ways we can use Maybe types to completely replace nulls. The biggest benefit is that it forces you to handle the case where Maybe is Nothing: with null, it’s easy to forget. Even in languages like Zig, the Maybe type is present, just hiding under a different guise.

              If this explanation didn’t really make sense, that’s fine, perhaps the Rust Book can explain it better. If you’re willing to get your hands dirty with a little bit of Rust, I find this guide to also be quite nice.

              TLDR: The Maybe monad is a much better alternative to nulls.

  • mindbleach@sh.itjust.works
    link
    fedilink
    arrow-up
    1
    ·
    2 years ago

    For the love of god, please do not use single-line alternatives to braced scopes. It’s only tolerable in lambdas like Array.map( v => v**2 ). It’s not for an implicit scope. It’s for evaluating a return value.

    But holy shit is it nice to have ?. in Javascript. It’s such an anything-goes language until you look at it funny and it just shits the bed and silently dies. Hate hate haaate having to check if things exist, when so many other details fail politely and impact nothing. At least now it’s one extra character instead of try-catch rigmarole.

    • PoolloverNathan@programming.dev
      link
      fedilink
      English
      arrow-up
      1
      ·
      2 years ago

      I’m fine with non-braced blocks, but they must always be on the same line as the parent statement (e.g. if (a != null) return a) to visually distinguish them. (inb4 argument about long conditions: they’d usually be spread out over several lines, and the statement would go on the closing parenthese (which is on a line by itself when split over multiple lines))

  • 30p87@feddit.de
    link
    fedilink
    arrow-up
    1
    ·
    2 years ago

    Except there’s literally no change in performance as a normal compiler will treat those the same. It just looks nice and trim down the time an experienced dev reads and understands the code by around 200ms.

  • heavyboots@lemmy.ml
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    2 years ago

    I hate this so much. Literally stopped using Perl and switched to PHP to get away from the “Look, ma! I can condense 6 comprehensible lines to one complete gibberish line that still works!” crowd.

    I’m not saying I won’t use shorthand if/else format on very rare occasions where you have to do a bunch of different if else’s within your HTML for some reason, but in general, I try to avoid it.

  • PoastRotato@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    2 years ago

    My coworker flips his shit every time I include a ternary operator in a PR. He also insists on refactoring any block of code longer than two lines into its own function, even when it’s only used once.

    He is not well liked.

  • maegul (he/they)@lemmy.ml
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    2 years ago

    Python, checking in …

    return (a or b)
    

    Parentheses aren’t necessary, I just prefer them for readability.

    See python documentation on boolean operators for reference. Short story is a or b is an expression that evaluates to a if a is “truthy” else b. “Falsy” is empty strings/containers, 0 and None.

    • KairuByte@lemmy.dbzer0.com
      link
      fedilink
      arrow-up
      4
      ·
      2 years ago

      I’m confused on how this is difficult to understand. Put aside the fact that it’s just a regular operator that… I mean virtually everyone should know, how hard is it to google “what does ?? mean in [language]” which has the added benefit of learning a new operator that can clean up your code?

      • DudeDudenson@lemmings.world
        link
        fedilink
        arrow-up
        1
        arrow-down
        1
        ·
        2 years ago

        If condition then this else that vs this ?? that

        Which option do you think requires less time for a person to identify and understand?

        Sure if it’s just your own code do whatever comes natural to you but there’s a reason we don’t use these kind of logical operators in day to day speech is my point.

        Ive been a backend dev for 2 years now and I’ve never come across the ?? operator and every time I come across a ternary operator I have to Google in what order comes what.

        Not saying it doesn’t make the code more concise and less “noisy” but sometimes a simple if else statement just makes the code easier to mantain

        • KairuByte@lemmy.dbzer0.com
          link
          fedilink
          arrow-up
          2
          arrow-down
          1
          ·
          2 years ago

          It’s easier to mess up return a != null ? a : b than it is return a ?? b, and operators work from left to right.

      • DonnerWolfBach@feddit.de
        link
        fedilink
        arrow-up
        1
        arrow-down
        2
        ·
        2 years ago

        Well yeah but imagine you had to do that on most lines of the code? It would become very distracting imho. If you are in a team with people that have a lot experience and or will learn more anyway this is fine. But if you are in a team with not very good programmers which “will never learn” because they have other stuff to do, you should be careful when using code like this. Though I would prefer in the former of course.

        • KairuByte@lemmy.dbzer0.com
          link
          fedilink
          arrow-up
          6
          arrow-down
          1
          ·
          2 years ago

          Honestly, and I mean this sincerely, if you’re on a team where the nullable coalesce is going to be confusing after the first handful of times encountered… look for a new job. It doesn’t bode well for their ability to do their jobs.

          This is like the guy at Walmart who needs hand holding each time they clean a machine, it’s a problem waiting to happen.

          • Zangoose@lemmy.world
            link
            fedilink
            English
            arrow-up
            2
            ·
            edit-2
            2 years ago

            Imo it’s context dependent. Obligatory “I’m only a college student/intern” out of the way.

            Whenever I’m working with a project with multiple languages (e.g. split frontend+backend, different connected services, etc.) operators like that can get blurry when they aren’t consistent between lancuages. Especially when one of those languages doesn’t have runtime type enforcement or has weird boolean behavior (looking at you JS/TS) which can lead to unintended behavior

            If everyone on the project is only working with that language, then your point is probably pretty close to the mark.