<p>If you are frustrated by trying to compile and you get an unused variable or import error, slowing you down, then don't answer this question please.</p>
<p>For people who have solved this question for themselves (i.e. are <em>no longer</em> frustrated by trying to compile and getting an unused variable or import error), what is the exact setup you use to save yourself this time?</p>
<p>Obviously if I hack up a solution for myself I am not going to be the 1 person out of the world's 300,000+ Golang developers who has done it.</p>
<p>So if others have hacked together a solution for themselves that they use, can you tell me:</p>
<ul>
<li><p>What is your platform?</p></li>
<li><p>What is your IDE?</p></li>
<li><p>What is the solution you adopted for yourself?</p></li>
</ul>
<p>There may be automated tooling I'm unaware of. I did Google "solve unused variable and import errors go" but saw nobody's solution that is outside of writing code.</p>
<p>I am looking for IDE-based and script-based, etc, solutions. So things outside of the Go language or program you are writing. I'm sure someone else has done it. Share your secret.</p>
<hr/>**评论：**<br/><br/>asokoloski: <pre><p>I think goimports can get you halfway there.</p>
<p><a href="https://godoc.org/golang.org/x/tools/cmd/goimports" rel="nofollow">https://godoc.org/golang.org/x/tools/cmd/goimports</a> </p></pre>gogroob: <pre><p>This ^
Works with all editors. What many miss in the beginning is that goimports = imports + gofmt. Find the setting in the editor that formats your code o save, and change it to use goimports instead, and you'll have both.</p>
<p>Unused variables:</p>
<p><code>
// TODO remove
_ = somevar
_ = someothervar
</code></p></pre>drvd: <pre><p>Platform: Linux. IDE: Emacs.</p>
<p>Solution for imports: goimports</p>
<p>Solution for unused variables: 95% of my unused variables are bugs so I'm happy the compiler detects them for me.</p></pre>nsd433: <pre><p>goimports, and use the vars by assigning them to _</p>
<pre><code>_ = otherwise_unused_var
</code></pre></pre>0xjnml: <pre><p>all_test.go: <code>func use(...interface{}) {}</code></p>
<p>foo.go: <code>use(bar, baz, qux.Foo)</code></p></pre>neoasterisk: <pre><ul>
<li>goimports solves half of your problem</li>
<li>Unused variables are usually bugs so even though they can be annoying sometimes I actually feel thankful the compiler works that way.</li>
</ul>
<p>I use two different setups. </p>
<p>One is very basic, opening 3-4 tabs on my Ubuntu terminal and use 1st for the editor (vim), 2nd for compilation, 3rd for git etc. It's so simple that it needs almost zero configuration.</p>
<p>The other involves using the <a href="https://www.youtube.com/watch?v=j1I63wGcvU4" rel="nofollow">i3 window manager</a> and similarly I open 3-4 tabs/windows for the different stuff I need.</p>
<p>The advantage of those setups is that I can switch between tabs incredibly fast, especially with i3 and I don't need to move my fingers away from the keyboard too much.</p>
<p>I think the complete solution is a combination of getting used to the unused variables, increase your speed of changing them through your setup and learning to mentally not leave unused variables.</p></pre>peterbourgon: <pre><p>This will sound snarky but it's not meant to be. Go is not a language that's suitable for this type of programming. You should arrive at your editor with a quite concrete plan of attack, and go about implementing your idea—as opposed to toying about with experiments so informal that these aspects of the language become burdensome. If you can change the way you think about prototyping, and change your behavior in turn, you're going to have a much better time.</p></pre>throwawaybeginr: <pre><p>This is actually extremely valuable insight. Because the language/syntax are small, it seems clear that you can write programs quickly - so your advice tempers this expectation.</p>
<p>Do you have any other examples which show that this is the way Go is "meant to be"?</p>
<p>After all, the approach you outline can be done with any compiled or interpreted language - there's no language you can't approach with "a quite concrete plan of attack". I'm curious what other language or tooling features in Go make you think that Go is more suitable for the type of programming you outline? Thank you.</p></pre>Sythe2o0: <pre><p>I really disagree with this. Goimports on save resolves import problems immediately, and once you've used go for a month or two you'll reflexively delete or comment out unused variables as you code.</p></pre>throwawaybeginr: <pre><blockquote>
<p>you'll reflexively delete or comment out unused variables as you code</p>
</blockquote>
<p>Very simply "or comment out" can be done programmatically.</p>
<p>It is possible to run a script htat says <code>/* commented out as unused by script xyz on sfdf*/ //</code></p>
<p>such as by a script that repeatedly tries to run to run the compiler and comments out those lines.</p>
<p>I'm not going to be the 1 person in 300,000 that has thought of this.</p></pre>Sythe2o0: <pre><p>I feel like you'd spend more time deleting those comments than it would save you</p></pre>throwawaybeginr: <pre><p>should also be an automatic step (I thought this was obvious, sorry.)</p></pre>Sythe2o0: <pre><p>How do you automatically remove a comment, how does it know what you want to remove?</p></pre>throwawaybeginr: <pre><p>I don't know, hence this thread? It could have a 'remove-by' date (like an expiration date on old milk) in some automatically read format and just get deleted after that date. I don't have a specific suggestion here. I was asking what hacks people actually use.</p></pre>Sythe2o0: <pre><p>You want your code to automatically delete itself if you don't make sure you uncomment it?</p>
<p>OK, because you say you're looking for what other people are using: No one is using this idea of a script that automatically comments things out. It is infeasible for a number of reasons. I already mentioned what I do.</p></pre>throwawaybeginr: <pre><p>Right, I didn't think it through completely yet, since I was sure others have. However it is also interesting that I <a href="https://www.reddit.com/r/golang/comments/6woy10/if_youve_solved_this_what_is_your_secret_hack/dman9pl/" rel="nofollow">got the feedback</a> in this thread that this wasn't really the "Go approach". Any thoughts on that?</p></pre>Sythe2o0: <pre><p>This thread started with me giving my thoughts on that. Once you've used go for a month or two you'll reflexively delete or comment out unused variables as you code. An IDE that highlights unused variables is usually sufficient, but if you think ahead of time you can iterate fast without worrying about it.</p></pre>Schpaencoder: <pre><p>IDE is gogland, obviously for the refactoring facilities</p></pre>bga9: <pre><p>gogland IDE + goimports, configured to run goimports on file save and using the format shortcut (cmd-shift-f iirc) to go fmt my project helps a lot.</p></pre>GoHomeGrandmaUrHigh: <pre><p>As the others have said: goimports. I use Atom with the go-plus plugin that installs that and a bunch of other nice things by default.</p>
<p>For unused variables: for me, I usually only have these if I'm in the middle of a new function I'm writing and wanna test what I have so far, so I usually only have one or two variables hanging out at the end. I either assign them to <code>_</code> instead of names, or just assign the names to <code>_</code> later, so that the variables are "used".</p>
<p>e.g.</p>
<pre><code>file, err := os.Open(filename)
if err != nil {
return err
}
_ = file // here, `file` gets used so its not an error
</code></pre></pre>Sythe2o0: <pre><p>Windows</p>
<p>VSCode</p>
<p>goimports on save (on by default with the Go extension) and writing sufficiently small functions that unused variables are never a problem (always easy to tell when they come up)</p></pre>cks: <pre><p>I use (GNU) Emacs for most of my Go coding. Goimports solves the unused imports problem by standing in for gofmt, since I almost always gofmt my code before running tests or building. Some people have Emacs set to auto-gofmt (ie auto-goimports) when they save files, but I don't like that because there are some situations where goimports can get it wrong.</p>
<p>To spot unused variables and other problems before running tests or building, I like Emacs' flycheck mode. This will more or less immediately highlight a whole collection of problems (not just unused variables) as I'm writing code or saving the file. Provided that I pay attention, this works great.</p>
<p>The other thing that you can do in Emacs is to run <code>go build</code> and/or <code>go test</code> from inside Emacs. When you do this and errors happen, Emacs will let you immediately jump to the location of the error. This reduces fixing these problems to <code>M-x compile</code>, click on things, apply edits, save again, repeat.</p></pre>PaluMacil: <pre><p>I print all variables that aren't used yet in a fmt.Println(r, err) since an underscore almost guarantees that the next bug will be what I'm ignoring. Then once I think I'm using all my variables correctly, I also search for fmt.Println since when I'm done, I should convert to log.Println even if I am still printing to a console.</p>
<p>I've seen others favor snippets to expand an "if err != nil" right away. I don't like snippets because it's more to remember. One of my coworkers just types out the err checks in the beginning and it doesn't bother him. A junior dev on the team does nothing and gets bitten. :) I'm not sure what they do for non-err variables that aren't used yet. I lean heavily upon Git, happy to delete code, and combined with my Println, never get bothered by the language feature.</p>
<p>My other details probably aren't important in this case since what I mentioned isn't very fancy, but I'll still be happy to share: Win 10 and deploying to Alpine in Docker; VS Code; just updated to Go 1.9 and Angular 4.3.6 for ongoing work. Running apps are mostly Go 1.8.x and no frontend, an Angular 4.2ish app, and then the other teams are mostly .Net Core, one massive AngularJS app with .Net Framework, two apps with Knockout, and statistics scheduled in Python.</p></pre>throwawaybeginr: <pre><p>thanks, this was really interesting.</p></pre>GreatDant0n: <pre><p>The easiest solution I know is to install VsCode with Go plugin.</p></pre>hell_0n_wheel: <pre><p>Sounds like you're trying to write Python, but using Golang instead.</p></pre>throwawaybeginr: <pre><p>if by that you mean that I make many iterations on working code while I prototype, yes, I get shit done :)</p></pre>hell_0n_wheel: <pre><p>No, by that I mean you're writing code that's peppered with unused variables and imports and expecting the interpreter to deal with it.</p>
<blockquote>
<p>I get shit done</p>
</blockquote>
<p>When "shit" is the product that's called for, that's fine...</p></pre>throwawaybeginr: <pre><p>I wasn't really expecting the compiler to deal with it. I was asking about hacks - something outside of Go, the source code, and its compiler - to let me one-button something to both remove that stuff out (by commenting it out), comment it back in if I do need it (by removing the auto-generated comment), or remove it entirely if I don't need it anymore (by removing the autogenerated comment and the line it referred to). Just a way to manually speed up what I do anyway.</p>
<p>So it is about speeding up the speed with which I do something that people do anyway.</p>
<p>You can't really tell me you've never encountered an unused variable error, because you always just type in your final product? :)</p></pre>hell_0n_wheel: <pre><p>Much faster to write correct code from the get-go than to write a bunch of crap, lean on tooling to fix your mess, then figure out why it doesn't work the way it did.</p>
<blockquote>
<p>You can't really tell me</p>
</blockquote>
<p>That's not an argument in favor of what you're doing.</p></pre>throwawaybeginr: <pre><p>This is interesting. Actually it's pretty insightful. So let me learn a bit from you :) Do you think through the architecture you will have? Do you go as far as write it down on pen and paper? Or do you work it out in the IDE, and only try to hit "compile" when you think you're ready?</p>
<p>In other languages, I have had a very fast turnaround cycle so that I always have something that compiles/works. I spend only short amounts of time writing new code before I test and make sure it's all still working.</p>
<p>curious how you approach Go instead of this.</p></pre>hell_0n_wheel: <pre><blockquote>
<p>Do you think through the architecture you will have? </p>
</blockquote>
<p>The code I write follows a set of basic principles / best practices: separate data and logic, build functions and classes with a single responsibility, etc. How that code is architected depends on the use case. If it's a production service, of course I work it out on paper... if it's just tooling I might sketch out some quick pseudocode, sleep on it, then fire away the next day.</p>
<p>In either case, I write code in smallish units, and write tests for each unit. Code is usually reusable, especially when written dogmatically, so there's little excuse to write throw-away code.</p>
<p>And none of this is specific to Go. I've done this in C++, in Python and in Go.</p></pre>throwawaybeginr: <pre><p>Thanks, this was interesting. You say "dogmatically" but can you share some of the rest of your dogma? I am listening attentively to your approach. Thanks.</p></pre>
