对所有成员函数和属性使用 "this" 是否是一种不良做法？

Is using "this" for all member functions and attributes bad practice?

本文关键字：一种不良是否是 this 成员函数属性更新时间：2023-10-16

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

我用过很多谷歌(但很难找到任何以"this"作为关键字的东西(，并环顾四周，但我只找到了一些何时必须使用this的例子。

我知道使用 this 是不可避免的情况(具有相同名称的参数/变量、模板继承等(，但随着时间的推移，我开始尽可能使用 this，因为我可以更容易、更快地找到绕过代码的方法。我的理由包括：

快速检查函数f是否应该是成员函数：如果代码中没有this，则可以将其从类中删除
快速检查f是否可以成为const功能：如果左侧没有this，则很可能可以const(并非总是如此，但我发现它在略读时很有用(
快速检查对象是否在f中以"预定义"的方式"改变"自身，或者它是否是一个复合成员函数(使用 this 调用的成员方法与在没有此的情况下对对象运行的"外部"算法(
调试;即，如果成员属性在任何时候被分配了错误的值，我必须专注于包含this的行才能找到问题，因为其他行不会改变对象

坦率地说，关于这是"不良做法"的评论让我有点不安。但是，一条评论本身并没有多大意义，所以我想问一下，对所有成员函数和属性一致地使用 this 有什么固有的坏处吗？如果是这样，是什么主要缺点使它超越了(可能是笨拙的，不受欢迎的或不普遍的(个人风格，并将其归入"不良做法"类别？

这个答案是基于意见的(正如其他人所指出的(。

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

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

没有技术原因为什么不能在任何地方使用。

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

考虑到通常this用于需要的地方，而不是其他地方。正如你所说，可能需要this是有原因的，当大多数程序员遇到this时，他们会想，"这里必须出于一个不明显的原因需要它。我想知道这是什么原因。

一致性是可维护代码的一个重要属性。在任何地方使用this的主要问题之一是它与大多数其他程序员的做法不一致。由于大多数其他程序员不会在任何地方this都使用它，因此当您在任何地方使用它时，这将使他们更难维护您的代码。