Share via


Brad Abrams --- API design hall of shame

Brad thinks the API AppDomainSetup.ShadowCopyFiles is API design hall of shame.

https://blogs.msdn.com/brada/archive/2005/11/17/494282.aspx

I don't think Brad is fair here. At best, it is just a not-so-well-designed API.

An API to be hall of shame should at least have one of the following problems:

1. An API can never be used.
2. An API that nobody can figure out what it does, nor how to use it.
3. An API that nobody uses (or knows, cares)
4. An API that damage a design completely.

Etc.

AppDomainSetup.ShadowCopyFiles is far from any of those.

Comments

  • Anonymous
    November 18, 2005
    First off, Brad says it. That settles it.

    Secondly, see the first one. Brad is the man, he knows API better than anyone. He writes the rules about what is good and what is bad. By disagreeing with you, you are BY DEFINITION wrong.
  • Anonymous
    November 18, 2005
    The comment has been removed
  • Anonymous
    November 18, 2005
    I agree, there are much worse in the frame work. The undocumented ones are the one that really erk me. I have used this API before and actually use it quite often. I will admit I thought it was odd that it took a string saying true or false but hey it was documented.

    2. An API that nobody can figure out what it does, nor how to use it. <<<< There are quite a few of those in there.
    Another one I stumbled across the other day.
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemconfigurationconfigxmldocumentclasstopic.asp
    Ok Great, A nice big public API. But Don't use it and no documentation on what it does or is. Actually I am half thinking this is a class I need and am going to end up writing on my own. I need a config file for a class library.

    3. An API that nobody uses (or knows, cares) <<< Link above. Another prime example no one knows it, it isn't documented, so why do I care it is there. There are a bunch of these public classes that are there in the framework we are not supposed to use. So why are they there and not private or Internal.
  • Anonymous
    November 18, 2005
    Oh I forgot another one of my favorite enumerations the DontCare Enumeration

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemdrawingimagingpixelformatclasstopic.asp
  • Anonymous
    November 18, 2005
    The comment has been removed
  • Anonymous
    November 29, 2005
    I'm leaning towards Brad's view of things. I can accept the boolean/string thing but the clincher for me is the inconsistant
    behaviour when setting the property to "false". Here's the code I've used to get a predicatable result...


    // Enable shadow copying - yes, this is a string value of "true" or "false".
    // NOTE: --> There is some inconsistancy here. If CachePath is set to a directory then even setting ShadowCopyFiles
    // "false" will still enable shadow copying. So to safely disable shadow copying leave both CachePath and ShadowCopyFiles null.
    if (shadowCopyFiles)
    {
    setup.ShadowCopyFiles = "true";
    setup.CachePath = pluginDirectory;
    }