在C++中过度使用`this`

Sma*_*acL 23 c++ refactoring this

我正在处理一个大型代码库,它始终使用以下构造

class MyClass
{
public:
  void f(int x);
private:
  int x;
};


void MyClass::f(int x)
{
'
'
  this->x = x;
'
'
}
Run Code Online (Sandbox Code Playgroud)

就个人而言,我总是使用,因此更喜欢这种形式

class MyClass
{
public:
  void f(int x);
private:
  int _x;
};


void MyClass::f(int x)
{
'
'
  _x = x;
'
'
}
Run Code Online (Sandbox Code Playgroud)

我更喜欢后者的原因是它更简洁(更少的代码=更少的潜在错误),并且我不喜欢在范围内同时拥有多个同名的变量,我可以避免它.也就是说,我现在越来越多地看到以前的用法.我不知道第二种方法有什么好处吗?(例如,对编译时的影响,使用模板化代码等等)两种方法的优点是否足够重要,另一方面是否重构?我要问的原因是,虽然我不喜欢代码中存在的第二种方法,但是引入更多错误的工作量和相关风险并不值得重构.

blt*_*txd 27

你的版本有点清洁,但是当你在它的时候,我会:

  1. 避免使用下划线:_x是可以的,直到有人选择_MyField这是一个保留名称.不允许使用大写字母后跟大写字母作为变量名称.请参阅:在C++标识符中使用下划线有哪些规则?
  2. 将属性设为私有或受保护:如果编译时更改是安全的,并且您将确保使用您的setter.
  3. this-> story有一个用途,例如在模板化代码中使字段名称取决于你的类型(可以解决一些查找问题).

通过使用显式this->(使用g ++ 3.4.3测试)修复的名称解析的一个小例子:

#include <iostream>
#include <ostream>

class A
{
public:
  int g_;
  A() : g_(1) {}
  const char* f() { return __FUNCTION__; }
};

const char* f() { return __FUNCTION__; }
int g_ = -1;

template < typename Base >
struct Derived : public Base
{
  void print_conflicts()
  {
    std::cout << f() << std::endl; // Calls ::f()
    std::cout << this->f() << std::endl; // Calls A::f()
    std::cout << g_ << std::endl; // Prints global g_
    std::cout << this->g_ << std::endl; // Prints A::g_
  }
};

int main(int argc, char* argv[])
{
   Derived< A >().print_conflicts();
   return EXIT_SUCCESS;
}
Run Code Online (Sandbox Code Playgroud)

  • 正确,但跟随你的维护者可能没有意识到这一点. (4认同)
  • 只要下一个字符是小写字母,前导下划线就可以了. (2认同)

Gro*_*roo 10

字段命名与codemell无关.正如尼尔所说,现场能见度是这里唯一的代码.

有关C++中命名约定的各种文章:

等等


Jem*_*Jem 5

Microsoft C# 编码标准鼓励使用“this”。它提供了良好的代码清晰度,并且旨在成为成员变量中使用 m_ 或 _ 或任何其他内容的标准。

老实说,无论如何,我真的不喜欢名称中的下划线,我曾经在所有成员前面加上一个“m”前缀。

  • 感谢您与我们分享您的变量命名偏好。 (4认同)
  • C# 和 C++ 是不同的语言。在 C++ 中,this-&gt; 有一个非常具体的用途,即强制在模板实例化上下文中作为成员查找标识符,而不是在模板定义上下文中查找。C++ 编码标准可能会合理地将 this-&gt; 的使用限制在真正需要它的地方。这不适用于 C#。 (2认同)