+1  A: 

Those are interesting guidelines, and I agree with them. It's interesting in that they are setting the rules based on "everything is a property except the following". That said, they are good guidelines for avoiding problems by defining something as a property that can cause issues later.

At the end of the day a property is just a structured method, so the rule of thumb I use is based on Object Orientation -- if the member represents data owned by the entity, it should be defined as a property; if it represents behavior of the entity it should be implemented as a method.

Guy Starbuck
A: 

Fully agreed.

According to the coding guidelines properties are "nouns" and methods are "verbs". Keep in mind that a user may call the property very often while thinking it would be a "cheap" operation.

On the other side it's usually expected that a method may "take more time", so a user considers about caching method results.

Michael Damatov
+3  A: 

They seem sound, and basically in line with MSDN member design guidelines:

http://msdn.microsoft.com/en-us/library/ms229059.aspx

One point that people sometimes seem to forget (*) is that callers should be able to set properties in any order. Particularly important for classes that support designers, as you can't be sure of the order generated code will set properties.

(*) I remember early versions of the Ajax Control Toolkit on Codeplex had numerous bugs due to developers forgetting this one.

As for "Calling the member twice in succession produces different results", every rule has an exception, as the property DateTime.Now illustrates.

Joe
DateTime.Now may be a literal exception, but logically it returns the same thing every call.
Dolphin
A: 

What's so interesting about those guidelines is that they are clearly an argument for having extension properties as well as extension methods. Shame.

Thom
How is this an argument for extension properties?
Scott Dorman
A: 

I never personally came to the conclusion or had the gut feeling that properties are fast, but the guidelines say they should be, so I just accept it.

I always struggle with what to name my slow "get" methods while avoiding FxCop warnings. GetPeopleList() sounds good to me, but then FxCop tells me it might be better as a property.

Greg
FxCop generates a lot of false positives. In a case like that, you're right to exclude the violation.
Joe
Generate/Build/RetrievePeopleList?
Dolphin