• ddh@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    208
    arrow-down
    13
    ·
    2 years ago

    As your future colleague wondering what the hell that variable is for, thanks Go.

    • Willem@kutsuya.dev
      link
      fedilink
      arrow-up
      70
      arrow-down
      1
      ·
      2 years ago

      I prefer for it to be just a warning so I can debug without trouble, the build system will just prevent me from completing the pull request with it (and any other warning).

    • Nioxic@lemmy.world
      link
      fedilink
      English
      arrow-up
      28
      arrow-down
      1
      ·
      2 years ago

      Isnt the syntax highlighting it as mever used?

      So why would they wonder?

      • Camilo@discuss.tchncs.de
        link
        fedilink
        arrow-up
        1
        arrow-down
        3
        ·
        2 years ago

        If it is a pure value, I’d assume yes, but if it is tied to a side effect (E.g. write its value to a file), then it would be not used but still could break your app if removed.

        I’m not familiar with rust language specifically, but generally that’s what could happen

    • MJBrune@beehaw.org
      link
      fedilink
      English
      arrow-up
      27
      arrow-down
      2
      ·
      2 years ago

      A quick “find all references” will point out it’s not used and can be deleted if it accidentally gets checked in but ideally, you have systems in place to not let it get checked into the main branch in the first place.

      • Flarp@kbin.social
        link
        fedilink
        arrow-up
        28
        arrow-down
        1
        ·
        2 years ago

        Yeah that should be looked for in a CI line check, not a compilation requirement

        • MJBrune@beehaw.org
          link
          fedilink
          arrow-up
          14
          ·
          edit-2
          2 years ago

          Or a linter. Or code reviews. Or anything else. The nice thing is that if the compiler doesn’t demand something, it can be given to the engineer as an option. The compiler should have the option to do it. The option could even be defaulted on. Afaik there is no way in Golang to disable that error (this is the line that does it: https://github.com/golang/go/blob/04fb929a5b7991ed0945d05ab8015c1721958d82/src/go/types/stmt.go#L67-L69). like --no-pedantics or such. Golang’s compiler openly refuses to give engineers more choices in what they think is the best system to handle it.

            • MJBrune@beehaw.org
              link
              fedilink
              arrow-up
              5
              ·
              2 years ago

              You’ve literally never commented out a line or two but left the variable declaration while debugging?

      • anemoia_one
        link
        fedilink
        English
        arrow-up
        5
        ·
        edit-2
        2 years ago

        Yeah any compiler should support environments or config files. Our CI would never work with without --env “stage”