SubMain的.NET编码标准PDF已开始显示在"赞助者"区域中，似乎表明该属性仅适用于逻辑数据成员(请参阅文档的第34-35页)。在以下情况下，认为方法合适：

该操作是一种转换，例如Object.ToString()。
该操作非常昂贵，以至于我们希望与用户进行交流，使他们应该考虑将结果缓存。
使用get访问器获取属性值将产生明显的副作用。
连续两次呼叫该成员会产生不同的结果。
执行顺序很重要。
该成员是静态的，但返回可以更改的值。
成员返回一个数组。

大多数开发人员是否同意上述属性与方法论点？如果是这样，为什么？如果没有，为什么不呢？

解决方案

这些是有趣的准则，我也同意。有趣的是，他们基于"除以下内容外，其他所有属性"来设置规则。也就是说，它们是通过将某些事物定义为可以在以后引起问题的属性来避免问题的良好准则。

归根结底，属性只是一种结构化方法，因此我使用的经验法则是基于对象定向的-如果成员表示实体拥有的数据，则应将其定义为属性；否则，将其定义为属性。如果它表示实体的行为，则应将其实现为方法。

完全同意。

根据编码准则，属性是"名词"，方法是"动词"。请记住，用户可能会非常频繁地调用该属性，同时认为这将是"廉价"操作。

另一方面，通常期望方法可能"花费更多时间"，因此用户考虑缓存方法结果。

它们看起来不错，并且基本上符合MSDN成员设计准则：

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

人们有时似乎会忘记(*)的一点是，调用者应该能够以任何顺序设置属性。对于支持设计人员的类尤其重要，因为我们无法确定生成的代码会设置属性。

(*)我记得Codeplex上的Ajax Control Toolkit的早期版本存在许多错误，这是由于开发人员忘记了这一错误。

至于"连续两次调用该成员会产生不同的结果"，每个规则都有一个例外，如属性DateTime.Now所示。

这些准则的有趣之处在于，它们显然是拥有扩展属性和扩展方法的一个论据。耻辱。

我从来没有亲自得出结论，也没有直觉过属性很快，但是指南说应该如此，所以我只接受它。

在避免FxCop警告的同时，我总是想用缓慢的" get"方法来命名。 GetPeopleList()对我来说听起来不错，但是FxCop告诉我，作为一个属性可能会更好。