Thursday, January 21, 2010

Flag Parameters are Evil! (Or at least unclear)

The more parameters you have in a method call, the more chances you have to screw things up. Moreover, method signatures with boolean parameters (flags) add in clarity problems, too – even if the input parameter is well-named.

Instead of exposing a non-private method with a flag, make that method private and instead expose two well-named, explicit methods which are simple facades over the newly private method.

Instead of

protected T CreateRestServiceInstance<T>(bool impersonateEnabled)


protected T CreateRestServiceInstanceAsServiceUser<T>()
   return CreateRestServiceInstance<T>(false);

protected T CreateRestServiceInstanceWithImpersonation<T>()
   return CreateRestServiceInstance<T>(true);

private T CreateRestServiceInstance<T>(bool impersonateEnabled) 
  //wonderful shiny stuff here

You’re making your class’s API explicit and clear, and you’re cutting the risk of someone goofing up and missing something important – like invoking a REST endpoint as a service account instead of impersonating the user.

Not that I’ve ever done this myself, mind you…

1 comment:

Chris said...

Agreed. Flags are evil, and not very extensible beyond yes/no.

The explicit case shown above is great. Let intellisense guide the developer into the depth of your API.

I think the jury is still out on Enum arguments though I tend to see them quite often.

Subscribe (RSS)

The Leadership Journey