API design hall of shame...

Here is a new one for the API design Hall of Shame…. It has been in the .NET Framework from V1.0 days and I can’t believe I didn’t know about it until today… Maybe I did know about it before but I blocked it out of my memory ;-)

This API takes “true” and “false” rather than a Boolean value true and false…

https://msdn2.microsoft.com/en-us/library/system.appdomainsetup.shadowcopyfiles.aspx

public string ShadowCopyFiles { get; set; }

A String containing the string value "true" to indicate that shadow copying is turned on; or "false" to indicate that shadow copying is turned off.

Obviously, I would have MUCH preferred

public bool ShadowCopyFiles { get; set; }

 

So I checked with the team that owns the API to get the “background” story… While no one that still works in the area would claim “credit” for this API, I did get the story. Apparently the rationale for using string was that the underlying infrastructure uses strings rather than bools. This is a classic argument and one you should be very wary of whenever you hear it. For the purpose of great API design you should separate your self from the implementation details for a moment and just ask “what would the user like\expect”.. and only deviate from that where there is a super compelling reason. There clearly is no in this case.

Other suggestions for the API design all of shame? Hopefully no new ones in .NET Framework 2.0.