如何轻松区分Python中的属性和方法？

Question

让我们看一下float类及其一些属性：

[
 ...,
 'as_integer_ratio',
 'conjugate',
 'fromhex',
 'hex',
 'imag',
 'is_integer',
 'real']

使用PEP008编码指南时，我有点不安，因为我不知道哪个是属性，哪个是方法。

例如，如何轻松地（无需尝试）知道是否需要编写foo.real或foo.real() 。 如果real是一个属性，为什么hex是一个方法？

在一个项目中，我选择使用CamelCase命名我的方法，并使用小写字母命名属性，但这与python编码样式不兼容。

为什么我自己的标准不是一个好主意（我认为这不是一个好主意，因为Python选择了其他命名约定）？

Answer 1

命名约定始终是主观的。 没有明确的“最佳”，否则整个世界都会跨语言使用它。

命名约定的最主观的品质可能是其应用的一致性。 一个拥有松散标准或松散遵守标准的团队可能最终会失去一致性，而一致性的丧失可能会导致对每个标识符的熟悉度下降和知识开销增加。 出于这个原因，有时如果没有太多规则和例外的情况下采用更简单的标准，可能会增加团队始终遵守这些标准的可能性。

使用PEP008编码指南时，我有点不安，因为我不知道哪个是属性，哪个是方法。

这里需要注意的一件事是，准确地说，我们可能应该声明您不知道标识符是代表属性还是基于其name的方法。

例如，如何轻松地（无需尝试）知道是否需要编写foo.real或foo.real（）。 如果real是一个属性，为什么十六进制是一个方法？

除了丰富的IDE功能外，命名约定通常无法帮助您提前知道什么。 例如，如果你的名字属性LikeThis和方法like_this ，那么我们从方法转移区分属性的智力开销名称（“这是什么叫什么？”，而不是“这是什么？”）。 但是，名称往往更明显，更突出（在文档，IDE和代码中），因此可能更容易记住，快速查找并跟踪哪种方式。 取决于您：这里的每个人的里程可能会有所不同。

为什么我自己的标准不是一个好主意（我认为这不是一个好主意，因为Python选择了其他命名约定）？

在他们的右脑中没有人可以说您的标准比Python的官方约定好或坏。 但是，当您选择偏离官方标准时，您会偏离习惯用法。

成语代码往往是大多数人最熟悉的，多年后重新访问代码时，也是您自己最熟悉的代码。 这是因为我们被它饱和了。 到处都有大多数Python示例将使用（略有偏离）的官方Python约定。 因此，这可能会使您的代码与其他人看起来有些陌生，甚至在遥远的将来也可能与您自己无关。

但是，如果您对此确实有强烈的感觉，那么您可能仍会坚持自己的标准。 但是，偏离官方标准时，应牢记这一风险。