4 ms·
Cool but please don't make it a compile error!
by jstanley 3y ago
Cool but please don't make it a compile error!
- AnimalMuppet 3y agoWell, unused imports are a compile error, so there's precedent.
- jstanley 3y agoYes, 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.
- fooster 3y agoHuh? Its a warning, not an error. https://go.dev/play/p/8GazBQv5xAb https://go.dev/play/p/8GazBQv5xAb
- jstanley 3y agoMy mistake!
- packetlost 3y agoIf you're finding you're doing this often, perhaps your functions are too large
- starttoaster 3y agoIf you find yourself doing this often, maybe a feature flag pattern using environment variables would end up being a bit nicer looking than throwing a bunch of unreachable code into your code base.
- radicalbyte 3y agoIt would break reflection surely? It's nice to have as a configuration / flag though as many project will be able to require it.
- erik_seaberg 3y agoLast I looked, reflection was missing a lot of things like looking up a function by name.
- zimpenfish 3y ago`MethodByName`[0] allows you to find a method on a struct but I'm assuming you must mean a generic package-level function rather than a method? [0] https://pkg.go.dev/reflect#Value.MethodByName https://pkg.go.dev/reflect#Value.MethodByName
- erik_seaberg 3y agoYeah, you can look up a method but only if you already have the receiver’s type (which you also can’t look up by name, or by listing a package).
- zimpenfish 3y agoYou don't need the receiver's type because you're calling `MethodByName` on a `reflect.Value` which you can construct from any receiver. https://go.dev/play/p/hg-ugl7i0ei https://go.dev/play/p/hg-ugl7i0ei demonstrates this, I think?
- enneff 3y agoGo’s reflect package is not “missing” that feature, it is intentionally omitted as it defeats static analysis. In all my years writing Go (14 now), including some tricky metaprogramming, I have never needed to look up a function by name.
- erik_seaberg 3y agoIt creates busywork and ongoing maintenance issues in writing an interpreter. E.g., https://pkg.go.dev/text/template https://pkg.go.dev/text/template requires every possible function to be manually registered, and that’s not a good use of time.
- codeflo 3y agoI still find Go too tolerant on this. It should scan your Git history and stash as well, and fail to compile if it finds any unused code there.
- SuperCuber 3y agoThat'd still be a bit too tolerant for my tastes. It should also scan your future commits.
- viscanti 3y agoThat'd still be a bit too tolerant for my tastes. It should have some kind of reinforcement signal that's stronger than just preventing the code from compiling. Some kind of shock therapy to help users learn and internalize things might be more appropriate here.
- lainga 3y agogo vet -basilisk ./...
- yobert 3y agoReally it needs to scan my coworkers commits as well. Can't be too careful.
- jerf 3y agoAh, I know the programming language for you: https://news.ycombinator.com/item?id=5002597 https://news.ycombinator.com/item?id=5002597
- mseepgood 3y agoCould you please expand on this? Why would local Git stashes relate to code quality?
- erik_seaberg 3y agoThat comment might not be entirely serious.
- dewey 3y agoWhy not? What do you gain by keeping unused code in the codebase?
- lynndotpy 3y agoWhen 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 agoIn reality you just comment out the block, in day-to-day work it really is a non-issue in my experience.
- lynndotpy 3y agoI 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 agoI 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.