Your expectations of Refactoring.

  • Article

Your expectations of Refactoring.

Cyrus posts about what you expect from Refactoring.  The particular issue he’s dealing with is Extract Method when the result will pass a generic argument to a method. 

He offers these three choices:

  1. Don’t add ‘ref’, potentially changing code behavior in a very subtle way.
  2. Always add ‘ref’, which may be unnecessary spam for you.
  3. Prompt the user to choose.

If we add an option, it will be on this UI:

I’m really wary of adding this as an option.  The default answer to every dialog box is "Cancel".  Users don’t want another option to think about.  Most of the time, they will just accept the default & move on.

In this case, the amount of brain energy required to understand the problem and make a decision is very high.  It’ll be pretty unusual for someone to make an educated decision about this bit of UI.

Now let’s look at the cost of making the wrong choice:

  1. If we don’t add ‘ref’ & you are passing a mutable value type & mutate it in the new method, you get a very subtle bug.  You have to discover the bug through some testing, analyze to find the cause, and fix it.
  2. If we add ‘ref’ and you know you don’t need it, you remove the word ‘ref’ from two locations in your code & continue about your day.

I really hope you aren’t using mutable value types in your code.  (In fact, once you’re done reading this blog, go review all your structs and make sure they’re immutable.)  However, if you are mutating value types, you’d really hate it if we broke you!

I vote for option #2 because it’s safer.  What do you want to see?  Go to Cyrus’s blog & say.

Note: this page has much cleaner HTML than usual.