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.
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: github.com/golang/go/blob/…/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.
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
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).
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
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.
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.
Please ignore everyone else being unkind - I’m somewhat new to build systems in general, what are the advantages/disadvantages of Bazel compared to other build systems?
It's very funny for sure and I was just about to share it with the other SWEs in our off-topic chat. But I just can't listen to it, had to close the tab after like 50 seconds. Perhaps on mute and with CC?
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.
I said ESLint. Not Javascript. ESLint is a linter for JavaScript. That’s why I put JavaScript in brackets. Some people don’t know what ESLint is. I’m talking about ESLint the whole time. Its not JavaScript specific but it’s mostly used for JavaScript
You yourself are talking about ESLint. You said that ESLint won’t prevent me from creating unused variables and functions when it clearly does. It won’t even run and throw an error
Edit: ohh it’s a Lemmy bug. The comment didn’t update yet. Originally I said “ES6” then I changed it to “JavaScript” and then I changed it to “ESLint (JavaScript)”
What the post is about is compiler based clean code enforcement. JS doesn’t do this, but your editor in combination with ESLint prevents you from running the program. However this isn’t a general JS thing, just the way your setup works.
Just saw your edit, and yeah, that makes sense as to the confusion.
Either way, your comment enquired as to whether it was “the same” and it still isn’t because for Go it’s a language feature and ESLint is not a language, it just allows you to create similar behaviour for JavaSvript which, by default, does not exhibit that behaviour.
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.