• CodeBlooded@programming.dev
    link
    fedilink
    arrow-up
    86
    arrow-down
    50
    ·
    edit-2
    1 year ago

    If this language feature is annoying to you, you are the problem. You 👏are 👏 the 👏 reason 👏 it 👏 exists.

    I worked in places where the developers loaded their code full of unused variables and dead code. It costs a lot of time reasoning about it during pull request and it costs a lot of time arguing with coworkers who swear that they’re going to need that code in there next week (they never need that code).

    This is a very attractive feature for a programming language in my opinion.

    PS: I’m still denying your pull request if you try to comment the code instead.

    ❗️EDIT: A lot of y’all have never been to programming hell and it shows. 🪖 I’m telling you, I’ve fixed bayonets in the trenches of dynamically typed Python, I’ve braved the rice paddies of CICD YAML mines, I’ve queried alongside SQL Team Six; I’ve seen things in production, things you’ll probably never see… things you should never see. It’s easy to be against an opinionated compiler having such a feature, but when you watch a prod deployment blow up on a Friday afternoon without an easy option to rollback AND hours later you find the bug after you were stalled by dead code, it changes you. Then… then you start to appreciate opinionated features like this one. 🫡

    • Urik@lemmy.ca
      link
      fedilink
      arrow-up
      53
      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
        5
        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
        10
        ·
        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
            2
            ·
            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.

    • AeonFelis@lemmy.world
      link
      fedilink
      arrow-up
      27
      arrow-down
      1
      ·
      1 year ago

      That’s what warnings are for. The jokes about programmers ignoring warnings are outdated - we live in an age where CIs run linters and style checkers on pull requests, there is no reason for a CI to not automatically reject code that builds with warnings.

    • pixeltree@lemmy.world
      link
      fedilink
      arrow-up
      22
      ·
      1 year ago

      I mean, yeah that kind of stuff absolutely should not be in production. However, it’s easy to see how it could be annoying while testing something while working on it. It being annoying doesn’t make it a bad feature, just as finding it annoying doesn’t make you a problem imo.

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

      I was working for a team that did quality control on the code of an entire financial group and it’s still amazing to me the shit we let through.
      I feel annoyed even having compiler warnings in my code and here we were downgrading errors into warnings so the code would go through, or adding rules exceptions for a program so the team responsible could push a hotfix to prod… It’s all shit. All the way down.

      I dream of working with such a strict language.