6 ms·
I'm using goimports too, and it works like magic 95% of the time, while I can manually take care of the rest. But it only solves the unused imports issue. Duri
by unscaled 10y ago
I'm using goimports too, and it works like magic 95% of the time, while I can manually take care of the rest.
But it only solves the unused imports issue. During development (especially when playing with code) I often need to temporarily comment out a section of code. I go build, and the situation usually unfolds like this:
- ERROR! Yes, now, I have an unused variable dangling around, because this code was using it.
- No problem, let's go on and comment out that variable as well.
- Oh noes! That variable was defined using two other variables which are now unused!
- The first one comes from a function result, but I still want to call that function, so I need to actually change (not comment out) the calling line to use an underscore.
- The second is a global variable which using another variable? Where is it going to end?
At this point I end up following the FAQ's advice and just add the line "_ = unusedVariable". The only problem I have with that is that wasn't all this unused variables thing meant to keep us from shipping code with useless bits we don't need in production? Now I actually might end up not using this variable, but because I've ended up adding "_ = unusedVariable" during my debugging and left that on, I have no way of knowing that.
- tptacek 10y agoThe unused variables are the things that can really cause bugs in your code. It's annoying, and I share your annoyance, but I have also sighed to myself and said "shit, I'm glad Go caught that" after noticing really bad bugs that the error flagged.
- junke 10y agoThat's why unused variables should be reported. What people are arguing about is errors vs. warnings. > things that can really cause bugs "can" means that they don't always cause bugs: other compilers treat such uncertainties as warnings because the human looking at the screen is the one who is in charge. Go allows you to compile code which does not respect "go fmt", why? aren't you afraid of committing working code that does not abide to the proper style? Improper formatting can lead to confusion, bugs and maintenance problems too, after all.
- tptacek 10y agoAs someone else pointed across the thread, the error eliminates these bugs, not only in your code but, effectively, in all the libraries you import. It takes effort to retain those bugs. That has significant value, and is why I've conclude Go's choice here was the right one, despite the annoyances it causes. I like gofmt, but I don't really care whether the compiler enforces it. It's unlikely to catch bugs.
- zzzcpan 10y agoActually, that's a huge speculation. Breaking someone's train of thought with an error that needs fixing right that second could just as well cause some bugs.
- junke 10y agoAnd so the compiler, who has no way to make informed decisions, is there to tell you which stylistic issues is more likely to introduce bugs or not, while being needlessly stubborn. A sufficiently bureaucratic compiler.