> renaming a variable (both of which should be entirely automated, and hardly count as refactoring)
Renaming is absolutely refactoring since refactoring is a process, not just individual acts but often a series of refactorings to achieve some goal. For instance, you may be trying to make two (or more) pieces of code look the same so you can replace them with a single implementation. A stupid kind of thing I saw and addressed recently (pretend these are more useful, simple examples for demo):
func some_fun(f *os.File) string {
var contents []byte
contents = make([]byte, 100)
count, _ := f.Read(contents)
return string(contents[0:count])
}
func same_fun_different_name(conn net.Conn) string {
buffer := make([]byte, 100)
n, _ := conn.Read(buffer)
return string(buffer[0:n])
}
These ought to be one function. They do the same thing but have different names, different names for internal variables, and different type signatures. But the types are actually unimportant, they both conform to the `io.Reader` interface. But the code doesn't
quite look the same, so if it were longer we might have a hard time believing the two functions are actually doing the same thing. So step 1 of the refactor is rename and reorganize the function internals so they match. Let's decide the second function's form is preferable (we flipped a coin):
func some_fun(f *os.File) string {
buffer := make([]byte, 100)
n, _ := f.Read(buffer)
return string(buffer[0:n])
}
Repeat as much as necessary and then you end up with one piece of code in the end that covers both cases (and many more):
func better_named_fun(reader io.Reader) string {
buffer := make([]byte, 100)
n, _ := reader.Read(buffer)
return string(buffer[0:n])
}
All thanks to refactoring by renaming.