<p>Sorry for the generic title, I would ask this on stack overflow but I feel like I always get way better answers/help here.</p>
<p>I have this simple code block</p>
<pre><code>var metric *Metric
if metric, ok := metricMap[metricName]; !ok {
metric = &Metric{}
metricMap[metricName] = metric
}
</code></pre>
<p>I can't figure out why <code>metric</code> is <code>nil</code> after the if statement if there was no entry in the map. Does the instance it's pointing to go out of scope and get garbage collected? I've run into this type of problem before and I can't figure out why it's happening.</p>
<hr/>**评论：**<br/><br/>Bake_Jailey: <pre><p>The <code>metric</code> in the if statement (as in the <code>if metric, ok := ...</code> one) shadows the variable above it, so when you assign to <code>metric</code>, you're not overwriting the one you're trying to.</p>
<p>You don't actually use the <code>metric</code> variable you look up, so you can replace it with a <code>_</code> to discard it. (Or, you can make use of defaults, and check <code>if found := metricMap[metricName]; found == nil</code>, but using <code>ok</code> is more clear to a reader.)</p>
<p><a href="https://play.golang.org/p/KeX1EVeR4S" rel="nofollow">https://play.golang.org/p/KeX1EVeR4S</a></p></pre>Destructicorn: <pre><p>Damn it...I thought I was assigning the outer metric in the if statement not creating a new one. That does make sense though thanks.</p></pre>theta_d: <pre><p>This is why shadowing should be a compiler error, IMO.</p></pre>Bake_Jailey: <pre><p>Shadowing is useful in many conditions, especially when checking errs, like when you do:</p>
<pre><code>something, err := doSomething()
...
if err := somethingElse(); err != nil {
...
}
</code></pre>
<p>I don't think making it a compiler error is the best idea, but it's not the worst either, since one could make the argument that you could just use a different name. At the same time if you're writing straight-line code that's just "do something, if error deal with it and return", which is a common theme in Go, then the errors will be short-lived anyway.</p>
<p>There are linters out there that check for issues relating for shadowing, which can help in lieu of any compiler help.</p></pre>qaisjp: <pre><p>One thing I hate in JavaScript is that ESlint errors if you shadow variables.</p>
<p>And because there are lots of callbacks, you need to check errors a lot. So you end up with errRequest, errCheck, errInsert, errDelete for each callback where you check the error</p></pre>wwader: <pre><p>I think the issue is that := will cause the if scope to have new variable named metric that shadows the outer one</p></pre>GentooMonk: <pre><p>For a pointer type you don't even need to check the ok, just check the value against nil.</p>
<p><a href="https://play.golang.org/p/SGcHXoViBM" rel="nofollow">https://play.golang.org/p/SGcHXoViBM</a></p></pre>Morgahl: <pre><p>There may be a valid reason to insert a nil for that map key, making a simple nil check not quite descriptive of the issue. The presence of the nil might be an important distinction to make.</p>
<p>Make the zero value useful :)</p></pre>GentooMonk: <pre><p>That is true.</p></pre>
