talks/2014/names: revise slides on local variables

I was overzealous about short local variable names.
On reflection I think my advice was too strong, and
the example I gave was hard even for me to read.

Change-Id: I3c300b95ac0453b9b5d1cfcd1e167965b643c817
Reviewed-on: https://go-review.googlesource.com/78135
Reviewed-by: Rob Pike <r@golang.org>

2014/names.slide

diff --git a/2014/names.slide b/2014/names.slide
index 199a7fa..6ba39ba 100644
--- a/2014/names.slide
+++ b/2014/names.slide
@@ -8,9 +8,6 @@
 https://golang.org/
 
 
-* An old joke
-
-
 * Names matter
 
 Readability is the defining quality of good code.
@@ -48,45 +45,54 @@
 
 Keep them short; long names obscure what the code _does_.
 
+Common variable/type combinations may use really short names:
+
 Prefer `i` to `index`.
 Prefer `r` to `reader`.
+Prefer `b` to `buffer`.
+
+Avoid redundant names, given their context:
+
+Prefer `count` to `runeCount` inside a function named `RuneCount`.
+Prefer `ok` to `keyInMap` in the statement
+
+	v, ok := m[k]
 
 Longer names may help in long functions, or functions with many local variables.
-
 (But often this just means you should refactor.)
 
 
 * Bad
 
 	func RuneCount(buffer []byte) int {
-		index, count := 0, 0
-		for index < len(buffer) {
+		runeCount := 0
+		for index := 0; index < len(buffer); {
 			if buffer[index] < RuneSelf {
 				index++
 			} else {
 				_, size := DecodeRune(buffer[index:])
 				index += size
 			}
-			count++
+			runeCount++
 		}
-		return count
+		return runeCount
 	}
 
 
 * Good
 
 	func RuneCount(b []byte) int {
-		i, n := 0, 0
-		for i < len(b) {
+		count := 0
+		for i := 0; i < len(b); {
 			if b[i] < RuneSelf {
 				i++
 			} else {
-				_, size := DecodeRune(b[i:])
-				i += size
+				_, n := DecodeRune(b[i:])
+				i += n
 			}
-			n++
+			count++
 		}
-		return n
+		return count
 	}