4 ms·

You'll love goimports then. https://godoc.org/golang.org/x/tools/cmd/goimports https://godoc.org/golang.org/x/tools/cmd/goimports Hook it to your editor's sav

• artursapek 11y ago
  I hate debugging someone else's code that has unused variables in it as much as this guy seems to hate the go compiler.
  • GreaterFool 11y ago
    Any normal compiler usually allows overriding these options. I normally write Haskell and it has it all: unused variables, unused imports, name shadowing, non-exhaustive pattern matching, everything. But these things are warnings in my dev build and errors in the release build. That's a sane way to do it.
    • Jabbles 11y ago
      Except some people wouldn't enable -Werror, and the quality of Go code would suffer on average. Plus, now your compiler has options.
      • artursapek 11y ago
        Yeah. I'm a fan of mandates when it comes to things like compiler options. Everyone should just suck it up and work with the same constraints. Warnings are just errors without balls.
• callumlocke 11y ago
  > On the other hand, stop leaving unused variables around... I don't think there's any problem with doing that. I use a linter to stop me committing code that has unused variables in it, and to highlight those kinds of style issues in my editor so I'm aware of them. But for a compiler to refuse to run unpolished code in development is just bad design. It's as if Go's designers took the hubristic or naive view that all code would, in an ideal world, be typed out perfectly first time, as opposed to being gradually hammered into shape through trial and error. This is worse than a design flaw, it feels like an active imposition.