Forums
Eric O was trawling through an API for handling concurrency, and found this little mismatch between the comment and the definition:
/// <summary>
/// private Status, because while this object needs to be able to set the status, consumers should only be able to check it, lest everything break.
/// </summary>
public StatusType Status {
get {
return _status;
}
set {
if (value != _status) {
RaisePropertyChanged("Status");
}
}
}
It's very important we make this property private, lest clients abuse it, and unleash dragons, chaos, and other potential horrors. Given that this happens inside of a concurrency API, I can only imagine what could go wrong when you mess this up. So sure, the comment makes sense.
The definition on the other hand, doesn't agree.
In practice, it's probably fine to do it this way, and at least the comment will show up in the documentation. If a consumer of the API misbehaves, they'll at least see that the docs suggest this is private.
The joke, of course, is the idea that the users of the API are going to read the docs, or care that one of the public methods suggests that it should be private.