As your future colleague wondering what the hell that variable is for, thanks Go.
this post was submitted on 14 Aug 2023
1370 points (97.9% liked)
Programmer Humor
19817 readers
56 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
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).
Changing it will bring down the entire system.
We've spent ten million dollars and do not know why.
Isnt the syntax highlighting it as mever used?
So why would they wonder?
load more comments
(1 replies)
Go is not a programming language. It's an angry rant of a bored Google engineer.
IDK, Brainfuck is still classified as a programming language and Go is not that far behind it.
Sometimes I think Go was specifically made for Google to dictate its own preferences on the rest of us like some kind of power play. It enforces one single style of programming too much.
Is this a hard error? Like it doesn't compile at all?
Isn't there something like #[allow(unused)] in Rust you can put over the declaration?
Yes it is a hard error and Go does not compile then. You can do _ = foobar to fake variable usage. I think this is okay for testing purposes.
I think that's even worse because it increases the likelihood you'll forget you faked that variable just for testing
load more comments
(3 replies)
load more comments
(4 replies)
Never really coded in Go outside of trying it out, but as far as I know it's a hard error.
I think this is a good thing. The styles are just opinions anyway and forcing everyone to just follow a single style takes a lot of bikeshedding away, which I really like.
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. 🫡
That's 👏 what 👏 CI 👏 is 👏 for
Warn in dev, enforce stuff like this in CI and block PRs that don't pass. Go is just being silly here, which is not surprising given that Rob Pike said
Syntax highlighting is juvenile. When I was a child, I was taught arithmetic using colored rods. I grew up and today I use monochromatic numerals.
The Go developers need to get over themselves.
Yeah, insisting on things like a variable being used will result in people using work arounds. It won't result in people not doing it.
Then, because people trust the language to police this rule, the work-arounds and debug code will get committed.
func main() {
test := true
}
Oops, golang doesn't like that.
func main() {
test := true
_ = test
}
Perfectly cromulent code.
If they really wanted to avoid people having unused variables, they should have used a naming convention. Any variable not prefixed by "_" or "_debug_" or whatever has to be used, for example. Then block any code being checked in that still contains those markers.
load more comments
(6 replies)
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.
load more comments
(6 replies)
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.
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.
load more comments
(1 replies)
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).
You should go to your team leader and ask them to enforce a coding standard. I agree with other commenters that said this should be a warning instead of an error.
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.
load more comments
(4 replies)
Also Go: exceptions aren't real, you declare and handle every error at every level or declare that you might return that error because go fuck yourself.
Because that's sane and readable?
Wow. I'm honestly surprised I'm getting downvotes for a joke. Also, no. It isn't. It really isn't.
load more comments
(3 replies)
It's better than "invisible" exceptions, but it's still the worst "better" version. The best solution is some version of the good old Result monad. Rust has the BEST error handling (at least in the languages i know). You must handle Errors, BUT they are just values, AND there's a easy, non-verbose way of passing on the error (the ? operator).
load more comments
(1 replies)
I'm with you, exceptions sound good but are a bug factory.
load more comments
(1 replies)
lints that underline unused vars as errors, and not notes or warns are the worst lints..
You go Go!
This makes me not want to use Golang at all.
I assure you, the feeling is mutual.
load more comments
(6 replies)
OP never said he/she commits such code but wants to iterate, test, explore.
Of course, unused var should not be part of a commit.
you can assign it to itself and it’ll be just fine. can’t put a breakpoint right on it, but it works
I hate this in C++ when it does this with parameters of an overidden function. I don't need that specific parameter, but if I omit the variable name, I reduce readability.
The best part of these threads is no matter what someone comments, at least 2 people will reply either correcting or "clarifying" the original commenter.
Lol
Me when my wife wants to buy new clothes (her clothes are the variables)
Comment the unused variable out and no security hole gets accidentally shipped.
view more: next ›