3 ms·

Why not? What do you gain by keeping unused code in the codebase?

by dewey 3y ago

lynndotpy 3y ago
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.
- dewey 3y ago
  In reality you just comment out the block, in day-to-day work it really is a non-issue in my experience.
  - lynndotpy 3y ago
    I get what you're saying, but I don't share your experiences. My reality is that I don't comment and uncomment lines, and I don't want to start. Commenting out a block of code takes more time and it's still unused code. It really feels like a "Go is designed around problems Google had within Google" design choice.
1zq 3y ago
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.
- dewey 3y ago
  > 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. The same tool that removes your imports also adds them so there usually isn’t an extra step.
  - nulld3v 3y ago
    It often breaks stuff for me when I import two packages with the same name so I use a named import: ``` import "alpha/stuff" import bstuff "beta/stuff" stuff.buyStuff() bstuff.stuffAnimal() ``` Once the autoformatter sees the named import is unused it removes it. Then when I uncomment my code again the autoformatter doesn't remember that it's supposed to use a named import. So in my example it wouldn't know "bstuff" is actually "beta/stuff".

Why not? What do you gain by keeping unused code in the codebase?

by dewey 3y ago

Why not? What do you gain by keeping unused code in the codebase?

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.

dewey 3y ago
In reality you just comment out the block, in day-to-day work it really is a non-issue in my experience.
- lynndotpy 3y ago
  I get what you're saying, but I don't share your experiences. My reality is that I don't comment and uncomment lines, and I don't want to start. Commenting out a block of code takes more time and it's still unused code. It really feels like a "Go is designed around problems Google had within Google" design choice.

1zq 3y ago

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.

dewey 3y ago
> 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. The same tool that removes your imports also adds them so there usually isn’t an extra step.
- nulld3v 3y ago
  It often breaks stuff for me when I import two packages with the same name so I use a named import: ``` import "alpha/stuff" import bstuff "beta/stuff" stuff.buyStuff() bstuff.stuffAnimal() ``` Once the autoformatter sees the named import is unused it removes it. Then when I uncomment my code again the autoformatter doesn't remember that it's supposed to use a named import. So in my example it wouldn't know "bstuff" is actually "beta/stuff".