From: Henry Maddocks <hmaddocks@...>
Date: 2012-12-27T06:43:34+09:00
Subject: Re: When to use Hashed Parameters for method calls.


On 27/12/2012, at 10:14 AM, Ricky Ng wrote:

> I should probably also note that I am working on a chunk of legacy code so a lot of things are pretty stinky right now. 
> 
> I know that I should refactor it, but being that this method has been around for 6 years now, I am extremely afraid of changing the interface. 
> 
> So I guess the more precise question is, during refactoring, how bad does it have to smell to warrant potentially causing code paths to fail, especially if there will be failures that won't be caught until down the road. 

I get the impression from what you said there are no tests for the method you want to refactpr. If so then I understand your fear.

I suggest your first step is write some tests to make sure you understand what the code does and to ensure your refactoing doesn't break anything. Then write a new method that has the same functionality as the original method (and passes the same tests) but is 'better' factored, eg. has a nicer interface. The old method can then delegate to your new method without breaking any other parts of the system. Then you can go hunting for callers of the old method and change them to call the new without fear of breaking something because you missed one.

Before you start though watch the following video...

http://www.youtube.com/watch?v=J4dlF0kcThQ

It might give you some inspiration.

Henry


PS. To answer your original question, I personally don't like hashed params because they hide the interface, but I occasionally use them because sometimes they 'feel' right. Looking back over my code it is usually when I have a lot of default or optional params.