I content there's something quite different between e.g. removing an unused argu...

Jtsummers · on Nov 2, 2022

> 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.

lmm · on Nov 2, 2022

> I content there's something quite different between e.g. removing an unused argument or renaming a variable (both of which should be entirely automated, and hardly count as refactoring) and separation of concerns, which concerns the purpose, architecture and operation of the code.

> I heartily endorse tidy code, good naming, etc. I would put that, though, in a separate category from refactoring.

I don't see the distinction. In either case you're trying to change the code into some equivalent code that's easier to comprehend; separation of concerns may involve more subjective judgement than applying consistent formatting to your source code (though I've seen plenty of subjective arguments about the right way to format code), but they're both the same kind of work.

> "Access to source code" is a maintenance goal, it just usually goes without saying and is rarely an issue.

I've never seen it considered a "goal" for any usual definition of goal. Rather keeping access to the source code is something you do as a means to an end; you want to make sure you can easily achieve future maintenance goals, even if you don't yet know what those goals are. And I'd take the view that refactoring to make your code more easily comprehensible is valuable in the same way and for the same reasons.