1426

submitted 2 years ago by mycroftholmess@lemm.ee to c/programmer_humor@programming.dev

140 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[-] DarkDarkHouse@lemmy.sdf.org 197 points 2 years ago

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

[-] Willem@kutsuya.dev 69 points 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).

[-] iforgotmyinstance@lemmy.world 42 points 2 years ago

Changing it will bring down the entire system.

We've spent ten million dollars and do not know why.

[-] Nioxic@lemmy.world 27 points 2 years ago

Isnt the syntax highlighting it as mever used?

So why would they wonder?

[-] Camilo@discuss.tchncs.de -2 points 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 25 points 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 27 points 2 years ago

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

[-] aport@programming.dev 9 points 2 years ago

You mean a system like the compiler

[-] MJBrune@beehaw.org 14 points 2 years ago* (last edited 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.

[-] aport@programming.dev -5 points 2 years ago

Who needs an option to leave unused variables around the code base? Lazybones?

[-] MJBrune@beehaw.org 5 points 2 years ago

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

[-] anemoia_one@lemmynsfw.com 5 points 2 years ago* (last edited 2 years ago)

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

[-] ennemi@hexbear.net 22 points 2 years ago* (last edited 2 years ago)

If only there was some way the compiler could detect unused variable declarations, and may be emit some sort of "warning", which would be sort of like an "error", but wouldn't cause the build to fail, and could be treated as an error in CI pipelines

[-] CoderKat@lemm.ee 5 points 2 years ago* (last edited 2 years ago)

Let's not pretend people acknowledge warnings, though. It's a popular meme that projects will have hundreds of warnings and that devs will ignore them all.

There's a perfectly valid use case for opinionated languages that don't let you get away with that. It's also similar to how go has gofmt to enforce a consistent formatting.

Honestly, I've been using Go for years and this unused variable error rarely comes up. When it does, it's trivial to resolve. But the error has saved me from bugs more often than it has wasted my time. Most commonly when you declare a new variable in a narrower scope when you intended to assign to the variable of the same name (since Go has separate declare vs assign operators).

[-] ennemi@hexbear.net 3 points 2 years ago* (last edited 2 years ago)

You can, if you want, opt into warnings causing your build to fail. This is commonly done in larger projects. If your merge request builds with warnings, it does not get merged.

In other words, it's not a bad idea to want to flag unused variables and prevent them from ending up in source control. It's a bad idea for the compiler to also pretend it's a linter, and for this behaviour to be forced on, which ironically breaks the Unix philosophy principle of doing one thing and doing it well.

Mind you, this is an extremely minor pain point, but frankly this is like most Go design choices wherein the idea isn't bad, but there exists a much better way to solve the problem.