对所有成员函数和属性使用“this”是不好的做法吗？ [关闭]

Posted 2023-02-22

【中文标题】对所有成员函数和属性使用“this”是不好的做法吗？ [关闭]

【英文标题】：Is using "this" for all member functions and attributes bad practice? [closed]

【发布时间】：2014-10-07 12:24:46

【问题描述】：

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

我用过很多谷歌（但很难用“this”作为关键字查找任何东西），并在这里四处寻找，但我只发现someexamplesthis有被使用。

我知道在某些情况下使用this 是不可避免的（同名的参数/变量、模板继承等），但随着时间的推移我开始尽可能使用this，因为我可以找到解决方法我的代码更容易更快。我的理由包括：

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

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

【问题讨论】：

这很可能是基于意见。我不认为有任何确凿的事实。就个人而言，我发现使用this 不需要分散注意力/烦人的噪音。

我想，已经解释过了***.com/questions/2337540/…我错了吗？

@juanchopanza 嘿，我看到你链接的帖子是重复的（以及我在 Q 中链接的另外两个类似的帖子）。然而，我我实际上是在寻找确凿的事实：我得到的评论的措辞表明它显然对每个人都应该清楚的原因，并且我应该能够找到自己。因此，虽然我同意每个人都有自己的个人偏好，但我想知道是否有任何确凿的事实证明这是糟糕的编码实践而不是不受欢迎编码风格。如果我尝试为此重新提出我的问题会有所帮助吗？

没有确凿的事实。因此，答案将是主观的。但如果你愿意，我可以重新打开它。

投票重新开放。问题不是基于意见的。如果有任何技术理由不在任何地方使用this，这个问题就很有效，而这个问题的答案是“不”。这个问题自然会导致一些基于意见的阐述，说明为什么它仍然是一个坏主意，但问题本身是基于事实的。如果基于意见的阐述的可能性是关闭标准，那么几乎可以将所有其他合法的问题作为基于意见的问题关闭。

【参考方案1】：

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

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

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

可能会变成纯杂货

）。

【讨论】：

this 是如何意外或使代码难以阅读的？即使你没有使用它的习惯，它的含义也很明显，不是吗？

这是出乎意料且难以阅读的，因为它非常罕见。我通常将这样的代码称为“精神减速带”。

我不同意使用“this”的代码更难阅读。如果您有阅读代码的经验，这对您来说应该是自动的。

它出乎意料或使代码难以阅读，因为我希望成员变量具有前缀的一些半健全的编码标准。如果一个方法采用与 mem var 同名的参数，所以这是必需的，那么这也是可怕的 IMO。

@Mauro C# 不需要使用this，如果您不需要的话。可能的原因是在 Visual Studio 中，键入 this. 将显示所有可用成员，从而更容易查找方法等。

【参考方案2】：

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

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

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

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

【讨论】：

有一个技术原因：如果在类模板中使用，this 可以对名称查找产生影响。见***.com/questions/10639053/…

@TobiasBrandt：这是必须使用this 的示例，而不是不能使用this 的示例？

是的，必须使用的地方。所以，这是肯定不是“坏习惯”的一种情况。

@TobiasBrandt：当然；我同意。但我不明白你的意思。

你最后一段认为所有 C++ 程序员都应该使用完全相同的风格编写 C++ 代码，这很难同意。