• Urik@lemmy.ca
    link
    fedilink
    arrow-up
    60
    arrow-down
    1
    ·
    edit-2
    1 year ago

    That’s a problem with your workplace, not the language nor OP.
    You could have a build setting for personal development where unused variables are not checked, and then a build setting for your CI system that will look for them. It gives you freedom to develop the way you want without being annoyed when you remove something just to test something, but will not merge your PR unless the stricter rules are met.

    • CodeBlooded@programming.dev
      link
      fedilink
      arrow-up
      7
      arrow-down
      3
      ·
      1 year ago

      I concur, it is a problem with that workplace. (In this case, OP is just sharing a funny meme. I wouldn’t suggest this meme means they’re a problem. I could have made this meme and I love the feature.)

      Developing on a team at a company is like the “Wild West.” What’s considered to be acceptable will not only vary from workplace to workplace, but it can also fluctuate as developers and managers come and Go. Each of them have their own unique personality with their own outlook on what “quality” code looks like. (And many of them do not care about code quality whatsoever. They just need to survive 1-2 years there, make management happy with speedy deliveries, and then they can move on to the next company with a 30% pay bump.)

      Having experienced working with developers who frequently filled with code base with unused code while having no control over who will leave or join as a contributor to the code base, I think features like this make for a more sane development experience when you’re developing with a team of seemingly random people that you never personally invited to contribute to the code base.

      will not merge your PR unless the stricter rules are met.

      This doesn’t fly when you work in big corporate and the boss doesn’t care about the code meeting stricter rules. “A working prototype? No it’s not- that’s an MVP! Deploy it to production now and move onto the next project!

    • LittleLordLimerick@lemm.ee
      link
      fedilink
      arrow-up
      5
      arrow-down
      11
      ·
      1 year ago

      Why in the world would you want to develop something that doesn’t follow the coding rules required by your org, just so you can go back and fix everything before submitting a PR? That’s just extra work.

      • planish@sh.itjust.works
        link
        fedilink
        arrow-up
        6
        arrow-down
        2
        ·
        1 year ago

        Because you want to know if the first half of the code works at all before you write the whole second half.

        Finding all the bits that will be used by the second half and changing the declarations to just expressions is a bunch of extra work. As is adding placeholder code to use the declared variables.

        • LittleLordLimerick@lemm.ee
          link
          fedilink
          arrow-up
          4
          arrow-down
          3
          ·
          1 year ago

          I’m having a hard time envisioning a situation where testing my code requires a bunch of unused variables. Just don’t declare the variables until you’ve started writing the code that uses them…

          • Urik@lemmy.ca
            link
            fedilink
            arrow-up
            3
            ·
            1 year ago

            Most of the time you don’t write the code, you change it.

            I had tons of situations where I wanted to test deleting a code block which just happened to use an imported library, which the compiler is now complaining about because it’s no longer being used.

            • LittleLordLimerick@lemm.ee
              link
              fedilink
              arrow-up
              1
              ·
              1 year ago

              If that’s the problem, then I would just use something like goimports to auto fix the imports every time I hit save. I never even see those errors so they don’t bother me.