4 ms·

I was being brief above. I agree with you, but allow me to elaborate: I see refactoring as one step in changing code to accommodate new requirements. The refact

I was being brief above. I agree with you, but allow me to elaborate: I see refactoring as one step in changing code to accommodate new requirements. The refactoring is caused by the changing requirement, but isn't enough by itself to fulfil the new requirement. > improve the quality without changing the behavior IMO, quality cannot be judged without reference to requirements, except in extreme cases. Within a broad range of "code that doesn't make your eyes bleed", comparing one approach to another is difficult to do without reference to how it specifically fulfils the requirements. When requirements change, they may reveal that your existing code doesn't fulfil them well, or doesn't easily generalise, can't be reused, etc. So when you need to change the code, it may first be necessary to do some refactoring. But refactoring without a prompt, without new knowledge entering via changed requirements, is just fiddling with aesthetics.

worthless-trash 4y ago
> is just fiddling with aesthetics. Commonly known as 'making your code more maintainable' so that the following programmers who work on that code do not find your address, look you up and murder you for your crimes against humanity.
- crabmusket 4y ago
  Every maintenance task is a requirement, in the light of which you should evaluate the quality of existing code! Maintenance isn't just something that hangs around in the air: it is made up of specific goals and activities.
  - worthless-trash 4y ago
    Not in any disagreement with anything you said.
  - lmm 4y ago
    Yes and no. Removing an unused parameter, for example, seems like something that's wise to do for the sake of code maintainability even if one has no specific future tasks/changes in mind. Likewise things like right-length variable names and proper separation of orthogonal concerns. The way I see it, any kind of future maintenance will involve understanding the current code, so unless you expect the code to be abandoned soon, refactoring to improve comprehensibility is legitimate. (Otherwise why even keep the source code at all? If you take the position that there's no point in maintainability without specific maintenance goals, why not keep only the compiled binaries?)
    - crabmusket 4y ago
      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. > Otherwise why even keep the source code at all? If you take the position that there's no point in maintainability without specific maintenance goals, why not keep only the compiled binaries? "Access to source code" is a maintenance goal, it just usually goes without saying and is rarely an issue. It also doesn't involve making any changes to the code, so I'd say it's also in a separate category to refactoring.
      - lmm 4y ago
        > 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.
      - Jtsummers 4y ago
        > 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.
kitkat_new 4y ago
> without new knowledge entering via changed requirements, is just fiddling with aesthetics. or simply reducing technical debt
- quickthrower2 4y ago
  The requirement being “we need to maintain thing thing!”
  - kitkat_new 4y ago
    which is not necessarily a requirement popping up just before reducing technical debt. Most likely this requirement was there from the beginning (serious project) or introduced later (like a prototype that had to go to production). But refactoring can occur multiple times at any time
    - quickthrower2 4y ago
      Yes that is my point too. it is a continuous requirement. you could have a boss knock on your cube everymorning and say “new requirements! if any packages need upgrading for security today or if there are any customer bug reports today work on them!” but it would get boring.

worthless-trash 4y ago

> is just fiddling with aesthetics. Commonly known as 'making your code more maintainable' so that the following programmers who work on that code do not find your address, look you up and murder you for your crimes against humanity.

crabmusket 4y ago
Every maintenance task is a requirement, in the light of which you should evaluate the quality of existing code! Maintenance isn't just something that hangs around in the air: it is made up of specific goals and activities.
- worthless-trash 4y ago
  Not in any disagreement with anything you said.
- lmm 4y ago
  Yes and no. Removing an unused parameter, for example, seems like something that's wise to do for the sake of code maintainability even if one has no specific future tasks/changes in mind. Likewise things like right-length variable names and proper separation of orthogonal concerns. The way I see it, any kind of future maintenance will involve understanding the current code, so unless you expect the code to be abandoned soon, refactoring to improve comprehensibility is legitimate. (Otherwise why even keep the source code at all? If you take the position that there's no point in maintainability without specific maintenance goals, why not keep only the compiled binaries?)
  - crabmusket 4y ago
    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. > Otherwise why even keep the source code at all? If you take the position that there's no point in maintainability without specific maintenance goals, why not keep only the compiled binaries? "Access to source code" is a maintenance goal, it just usually goes without saying and is rarely an issue. It also doesn't involve making any changes to the code, so I'd say it's also in a separate category to refactoring.
    - lmm 4y ago
      > 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.
    - Jtsummers 4y ago
      > 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.

kitkat_new 4y ago

> without new knowledge entering via changed requirements, is just fiddling with aesthetics. or simply reducing technical debt

quickthrower2 4y ago
The requirement being “we need to maintain thing thing!”
- kitkat_new 4y ago
  which is not necessarily a requirement popping up just before reducing technical debt. Most likely this requirement was there from the beginning (serious project) or introduced later (like a prototype that had to go to production). But refactoring can occur multiple times at any time
  - quickthrower2 4y ago
    Yes that is my point too. it is a continuous requirement. you could have a boss knock on your cube everymorning and say “new requirements! if any packages need upgrading for security today or if there are any customer bug reports today work on them!” but it would get boring.