4 ms·
This kind of code clean up should be the job of IDE's, not compilers. Sadly, it looks like the Go authors have never heard of those.
by laureny 14y ago
This kind of code clean up should be the job of IDE's, not compilers. Sadly, it looks like the Go authors have never heard of those.
- Flow 14y agoUnless code cleanup is enforced by the IDE/checkin it will not always be done. Here at work we have VS2010, TFS, Resharper and yet some developers don't care about unused imports and references. Some developers use "dark themes" and it seems they don't see all the gray code that can be cleaned up. I'd love this to be hard errors like in Go, but it's too late now.
- egeozcan 14y agoWell you have stylecop.
- Flow 14y agoYeah, but it's too late. :-/
- RHSeeger 14y agoI fail to see the draw to the argument that, because some people are bad developers, the rest of us should be handicapped. Making the worst developers better at the cost of making the better developers worse (productivity-wise) doesn't seem like a valid tradeoff unless the gain on the lower end far outweighs the loss on the upper end.
- 4ad 14y agoGo ships with a Go parser in the standard library. Among other things it is used by gofix, gofmt and go vet. People from the community have used it for writing various refactoring tools. It's incredibly useful; I don't want to go back to a language that doesn't ship with a parser in the standard library. I'd say the Go authors have thought about support for tooling much more than other language authors, not less.
- stcredzero 14y ago> This kind of code clean up should be the job of IDE's, not compilers. Why should it be the province of IDEs? What about command line tools? How about "any thing that works well?"