For those interested in this topic, I worked on improving dead code elimination in js_of_ocaml [1], a compiler from OCaml to JavaScript. The problem is more difficult in that case because of the indirection of OCaml's higher-order modules (functors).
Finds unreachable functions but does not seem to find dead code in sense of unused writes to a variable (unless I misread the article). Guess there's something else that already catches that in Go?
I definitely don't want to keep unused code in version control, but for debugging or for working on things iteratively as the sibling comment said, my Go code usually ends up peppered with
if 1==2 { ...some code to temporarily disable ... }
"Just comment it out" is not always enough because when I want to quickly toggle the code on and off multiple times in a single session, it's not possible to do by only commenting/uncommenting that single block.
Sometimes the code that's commented out contains the only reference to an imported package, and by commenting it out the autoformatter helpfully removes the import from the top of the file, so then uncommenting the line is not enough -- I need to go back and re-add the import.
Or I may want to comment out this line
x = f(a, b)
but that makes a and b in turn become unused as well, and I need to travel up to wherever they're defined and comment them out too, and so on with anything else that became thus unused in that chain.
And this is all suboptimal because the warning is also important when debugging. I do want to get warned about the unused code! Just let me compile.
When I was doing Genuary in Rust, I started with a template that I would add some helper functions too that I could anticipate I would need for the art. Easy ones like "xy_to_polar".
I would do the first-time compile on this template and then add things iteratively.
Go would be a nonstarter for this experimental/artistic code, because I would usually have dead code in my "toolbox" to iterate and experiment with until I liked the end product.
Yes, unreachable code after a "return" in a function is also a compile error. Very frustrating when I just want to nop out part of a function for debugging something else and have to keep fighting the compiler until I find a way that is acceptable.
Sweet. For some reason, this has been an ongoing problem with Go’s tooling. I’m sure that there’s some underlying reason why the dead code finding tools have kept getting deprecated or had various problems.
I'm somewhat confused about this because I've had gopls installed with vscode for years now, and as far back as I can remember, it always gave me a little yellow underlining warning when I had unused functions or unreachable blocks of code inside `if` or `switch-case` statements. It would seem to me that this has existed for a long time, or maybe it just builds on top of what was already there?
I inherited a go project that has two different commands under `cmd`, and it seems when I run this against one of those `main`s, it incorrectly detects what it thinks as dead code that is used in the other command.
The given example is a poor choice. Capitalized elements are public, and it's not safe to assume this code isn't being used as a library by other code outside the immediate repo.
TL;DR: if your project is a library and an exported function looks like dead code, that means it isn't covered by any tests, and you should probably fix that.
Readit News
[1]: https://www.micahcantor.com/blog/js-of-ocaml-dead-code/
golangci-lint rolls up lot of linters and checkers into a single binary.
There is a config file too.
https://github.com/golangci/golangci-lint
Sometimes the code that's commented out contains the only reference to an imported package, and by commenting it out the autoformatter helpfully removes the import from the top of the file, so then uncommenting the line is not enough -- I need to go back and re-add the import.
Or I may want to comment out this line
but that makes a and b in turn become unused as well, and I need to travel up to wherever they're defined and comment them out too, and so on with anything else that became thus unused in that chain.And this is all suboptimal because the warning is also important when debugging. I do want to get warned about the unused code! Just let me compile.
I would do the first-time compile on this template and then add things iteratively.
Go would be a nonstarter for this experimental/artistic code, because I would usually have dead code in my "toolbox" to iterate and experiment with until I liked the end product.
Does anyone know how to work around this?
TL;DR: if your project is a library and an exported function looks like dead code, that means it isn't covered by any tests, and you should probably fix that.