I posted a quip on twitter this evening:

note to devs: a boolean property that expects to be set to only a false or true value (and throws otherwise) should be a method instead.

Several people prodded me for more an explanation, so here it is.

Say you have a default feature, and you want to offer consumers of an object the ability to disable the feature.  One common practice is to use a boolean property, consumed like so:

// ...
thingWithFeature.DisableFeature = true;
// ... 

It's simple and makes sense.  However, I'm finding a lot of hardware SDKs are throwing exceptions when you try to set such a property to false, in this example indicating that you do not want to disable the feature (forgive the double negative).  In other words, the property is settable to one specific value.  E.g., the SDK implementation looks something like this:

// ...
public bool DisableFeature
{
    set
    {
            if( ! value )
            {
                throw new ArgumentException();
            }
            
            // ... disable the feature when the value is false
    }
}
// ...

As a consumer of this object, there is only one path I can take with the DisableFeature property that will result in a valid operation.  The property syntax goads the consumer into failure by offering up an illusion of functionality that does not exist.  As a developer, I have every reason to assume that a boolean property can be set to true OR false.  If one of those is not appropriate, then the property isn't a property, it's a method:

// ...
public bool DisableFeature()
{
    // ... disable the feature
}
// ...

As a method, the one valid path is captured unequivocally, and it's not possible for consumers to assume they can do more than they are allowed by the SDK.