On 11/01/2014 06:13 PM, Orchid Win7 v1 wrote:
> There are a few things I don't agree with. The book asserts that a
> method should never have a bool argument. Because "if it has a bool
> argument, it does two different things, and you should change it into
> two separate methods instead". Yeah, and are you going to split every
> single client of this method into two methods as well??

To be fair, I think the expectation here is that some clients only use 
one variant, and other clients only use the other.

For example, you wouldn't write one function that takes a bool and a 
handle, and either opens or closes that handle based on the bool; you'd 
write one function to open handles, and another to close them. It would 
be silly to do otherwise.

But then again, would you write one function to open handles in read 
mode, and another to open them in write mode? That seems daft to me.

The other thing that concerns me is the potential amount of code 
duplication if you split one function into two. Maybe that bool 
parameter only affects one tiny weeny little portion of the function's 
contents. Do we really need to duplicate all that??

On the first hand again, I have certainly seen functions that take a 
bool parameter and do so much jiggery-pokery with it internally to get 
the right thing to happen in both cases that it would seem _more_ 
sensible to just write two functions that people can actually read.

I guess it depends on just how similar or not the two actions are.

Post a reply to this message