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. 🫡

[–] [email protected] 59 points 1 year ago* (last edited 1 year ago) (6 children)

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 4 points 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!”

load more comments (5 replies)

load more comments (26 replies)