Hacker News new | past | comments | ask | show | jobs | submit login

You are human, humans forget, humans get distracted, humans think that their situation is the exception that makes the rule.

A program doesn't suffer from that. Forcing these things to be showstoppers makes sure they NEVER become a problem, and the "cost" (in terms of the developer) is pretty small in the grand scheme of things.

How in the world forcing someone to put an underscore before the import name or adding a dummy variable to use the import (both should be removed after the debugging) helps to avoid bugs instead of making easier to introduce them?

Adding a dummy var won't work, because then the dummy var will trip the "no unused variables" check.

Adding a _ to the front of an import is not the correct way to get around this "problem" during development, commenting out the whole import is the correct way. That way if you forget, it's not in your code anywhere (as it shouldn't be since it isn't used).

The underscore system is meant only to be used when you need to import for side effects (something that i've never actually needed to use).

I have seen both suggestions in this thread: var _ = unusedImport

If you can't even agree among yourselves what is the right thing to do then I think that this is another sign that this go behaviour is not the proper solution.

If you have seen other people suggest that using a _ for an unused import that is unused because you commented out the variables using it, they are just doing more work for a worse result.

If you comment out code that uses an import, comment out the import too. It's not just the recommended way, it's the only logical way of doing things.

And how is having 2 opinions on how to do something a sign that this is not the proper solution? People still can't agree on tabs vs spaces (and probably never will be able to), that doesn't mean that all programming isn't a proper solution. There are also people that think using version control is a bad idea, but that doesn't mean that all version control is broken...

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact