使用“this”对所有成员函数和属性进行不良实践？

Question

最近我在这里发布了一段代码并得到了一条评论（与原始问题无关）使用this 所有成员函数和类的属性是“不仅仅是个人编码风格的问题，这是不好的做法”。不幸的是，这个人拒绝详细说明并告诉我自己查阅。

我已经使用了Google一堆（但是很难用“this”作为关键字查找任何内容），并在这里查看，但我只找到some examples时的{{1 必须使用。

我知道使用this是不可避免的情况（参数/变量具有相同的名称，模板继承等），但在时间我尽可能开始使用this，因为我可以找到我的方法更容易，更快。我的理由包括：

• 快速检查函数this是否应该是成员函数：如果代码中没有f，则可以将其从类中取出
• 快速检查this是否可以是f函数：如果左侧没有const，则最有可能this（并非总是如此，但我发现它在略读时很有用）
• 快速检查对象是否在const中以“预定义”方式“更改”自身，或者它是否为复合成员函数（使用f调用的成员方法与“外部”没有这个操作对象的算法）
• 调试;即如果成员属性在任何时候被赋予错误的值，我必须专注于包含this的行来找到问题，因为其他行不会更改对象

坦率地说，关于这种“不良做法”的评论让我感到不安。但是，一条评论本身并不多，所以我想问一下对于所有成员函数和属性，一致地使用this是否有任何不妥之处？如果是这样，主要缺点是什么让它超越（可能是笨拙的，不受欢迎的或不普遍的）个人风格，并将其置于“不良实践”类别中？

Answer 1

这个答案是基于意见的（正如其他人所指出的那样）。

我认为这是一种不好的做法，因为：

• 它使代码更大，不必要（最容易维护的代码，是你不会写的，因为你不必）。
• 这是意料之外的（而你可能会期待它，其他人赢了 - 所以你的代码中的WTF / SLOC比率增加了）
• 会增加维护成本。
• 需要额外的努力来保持代码的一致性（很少或没有额外的好处）。
• 虽然它看起来是一致的，但它是多余的（类似于使用语法class <class-name> var;声明所有对象实例，而不是<class-name> var;并且忽略零＆＃34;的＆＃34;规则。
• 它创造的编码习惯不适合大多数开发团队和编码标准。
• 更好的做法是重命名变量和函数以避免名称冒号而不是使用this->（因为用于类，函数和变量的名称构成了用于理解结构的心理模型代码）。
• 在不遵循/接受此练习的代码库中工作几个月后，您可能会发现自己的代码难以阅读/维护（换句话说，在一年左右的时间内它可能会变成纯粹的残酷）。

Answer 2

没有任何技术原因导致无法在任何地方使用它。

如果您只对技术原因感兴趣，那就是您的答案。但是，我会恳请你考虑非技术原因。出于某种原因形成意见，其中一些原因可能是好的。例如，我建议在任何地方使用它会降低代码的可维护性，并且通过重新考虑命名方案可以更好地服务。

考虑通常this用于需要的地方，而不是其他地方。正如你所说，有可能需要this的原因，并且当大多数程序员遇到this时，他们会对自己感到疑惑，“这里必须有一个非显而易见的原因。我想知道是什么原因是。“

一致性是可维护代码的重要属性。使用this无处不在的一个主要问题是它与大多数其他程序员的做法不一致。由于大多数其他程序员不会在任何地方使用this，当你做在任何地方使用它时，它会使他们更难以维护你的< / em>代码。