>最近我在这里发布了一段代码,并得到了一条评论(与原始问题无关(,即对类的所有成员函数和属性使用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
都使用它,因此当您在任何地方使用它时,这将使他们更难维护您的代码。