C ++에서 'this'의 과도한 사용 [복제

Question

이 질문은 이미 여기에 답이 있습니다.

• 언제`the '포인터를 명시 적으로 사용해야합니까? 12 답변

나는 다음과 같은 구성을 사용하는 대형 코드베이스를 다루고 있습니다.

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


void MyClass::f(int x)
{
'
'
  this->x = x;
'
'
}

개인적으로, 나는 항상 사용했기 때문에 양식을 선호합니다.

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


void MyClass::f(int x)
{
'
'
  _x = x;
'
'
}

후자를 선호하는 이유는 더 간결하고 (코드가 적음 = 더 적은 잠재적 버그), 피할 수있는 동시에 같은 이름의 여러 변수를 스코프에 갖는 것을 좋아하지 않기 때문입니다. 즉, 나는 요즘 이전의 사용법을 점점 더 자주보고 있습니다. 내가 알지 못하는 두 번째 접근 방식이 있습니까? (예 : 컴파일 시간에 미치는 영향, 템플릿 코드와 함께 사용하는 등 ...) 두 가지 접근의 장점은 상대방에 대한 충분한 장점입니까? 코드에 존재하는 두 번째 접근 방식이 마음에 들지 않지만 추가 버그를 도입 할 수있는 노력의 양과 관련 위험이 리팩토러가 될 수는 없습니다.

Answer 1

당신의 버전은 약간 깨끗하지만, 당신이 그것에있는 동안 나는 다음과 같습니다.

1. 선행 밑줄을 피하십시오 : _X는 누군가가 예약 된 이름 인 _myfield를 선택할 때까지 괜찮습니다. 초기 밑줄과 대문자는 변수 이름으로 허용되지 않습니다. 보다: C ++ 식별자에서 밑줄을 사용하는 것에 대한 규칙은 무엇입니까?
2. 속성을 비공개로 만들거나 보호하십시오. 변경 사항이 컴파일되면 안전하며 세터가 사용되도록합니다.
3. 이-> 스토리는 예를 들어 템플릿 코드에서 사용하여 필드 이름을 유형에 따라 사용합니다 (일부 조회 문제를 해결할 수 있음).

명시 적 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;
}

Answer 2

필드 이름 지정은 CodesMell과 관련이 없습니다. 처럼 닐 말했다. 현장 가시성은 여기에서 유일한 코드 멜로입니다.

C ++에는 이름 지정 규칙에 관한 다양한 기사가 있습니다.

• 공공 및 민간 변수에 대한 명명 대회?
• 개인 방법 명명 컨벤션
• C ++ 네임 스페이스 사용 및 이름 지정 규칙

등.

Answer 3

이 'this'사용은 Microsoft C# 코딩 표준에 의해 권장됩니다. 좋은 코드 선명도를 제공하며 M_ 또는 _ 또는 멤버 변수의 다른 사용에 대한 표준이되도록 의도되었습니다.

솔직히, 나는 어쨌든 이름으로 밑줄을 싫어합니다. 나는 단일 'M'로 모든 멤버를 접두사했습니다.

Answer 4

많은 사람들이 IDE에서 현재 클래스의 식별자 목록이 팝업되기 때문에 이것을 사용합니다.

나는 내가 BCB에서한다는 것을 안다.

이름 지정 갈등을 제공하는 예는 예외라고 생각합니다. 그러나 Delphi에서는 스타일 지침은이를 피하기 위해 매개 변수에 대한 접두사 (일반적으로 "A")를 사용합니다.

Answer 5

내 개인적인 느낌은 기존 코딩 컨벤션과 싸우는 것이 당신이하지 말아야 할 일이라는 것입니다. Sutter/Alexandrescu가 책을 'C ++ 코딩 컨벤션'에 넣었을 때 : 작은 물건을 땀을 흘리지 마십시오. 'this->'또는 '_'또는 그 밖의 선행이 있든 누구나 누구나 읽을 수 있습니다.

그러나 명명 규칙의 일관성은 일반적으로 원하는 것이므로 일부 범위 (적어도 파일 범위, 이상적으로는 전체 코드 기반)에서 하나의 컨벤션을 고수하는 것이 좋습니다. 이 스타일은 더 큰 코드 기반에서 사용된다고 언급 했으므로 다른 컨벤션을 개조하는 것이 다소 나쁜 생각이라고 생각합니다.

결국, 교체할만한 이유가 있다면 수동으로하지 마십시오. 최선의 경우, IDE는 이러한 종류의 '리팩토링'을 지원합니다. 그렇지 않으면 변경하기위한 스크립트를 작성하십시오. 검색 및 교체는 마지막 옵션이어야합니다. 어쨌든 백업 (소스 제어)과 일종의 자동 테스트 시설이 있어야합니다. 그렇지 않으면 당신은 그것으로 재미가 없습니다.

Answer 6

이런 식으로 '이것'을 사용하는 것은 코드 냄새가 아니라 단순히 개인적인 취향입니다. 따라서 시스템의 나머지 코드와 일관성있는만큼 중요하지 않습니다. 이 코드가 일관되지 않으면 다른 코드와 일치하도록 변경할 수 있습니다. 변경하면 코드의 나머지 부분의 대부분과 불일치가 발생하면 매우 나쁘고 내버려 둘 것입니다.

당신은 코드 테니스를하는 위치에 들어가기를 원하지 않습니다. 여기서 누군가가 순전히 무언가를 순수하게 바꾸어 다른 사람이 다른 취향과 함께 나중에 다시 만나기 위해 "좋은"것으로 보이게합니다.

Answer 7

나는 항상 사용합니다 중_ 이름 지정 컨벤션. 일반적으로 "헝가리 표기법"을 싫어하지만 클래스 멤버 데이터로 작업하는 경우 매우 명확하게 보는 것이 매우 유용합니다. 또한 동일한 범위에서 동일한 2 개의 변수 이름을 사용하여 오류가 발생하기 쉬운 것을 발견했습니다.

Answer 8

동의한다. 나는 그 이름 지정 규칙을 좋아하지 않습니다 - 나는 멤버 변수와 로컬 변수 사이에 명백한 차이가있는 것을 선호합니다. 당신이 떠나면 어떻게됩니까? this?

Answer 9

class MyClass{
public:  
  int x;  
  void f(int xval);
};
//
void MyClass::f(int xval){  
  x = xval;
}

Answer 10

제 생각에는 이것 코드에 혼란을 더하는 경향이 있으므로 다른 변수 이름을 사용하는 경향이 있습니다 (컨벤션에 따라 밑줄 일 수 있습니다. 중_, 무엇이든).

Answer 11

class MyClass
{
public:
  int m_x;
  void f(int p_x);
};


void MyClass::f(int p_x)
{
  m_x = p_x;
}

... 스코프 접두사를 사용하는 내가 선호하는 방법입니다. 멤버의 경우 M_, 매개 변수의 P_ (일부는 인수에 A_을 대신 사용), Global의 경우 G_, 때로는 가독성에 도움이되는 경우 L_.

같은 이름을 가질 자격이있는 두 가지 변수가 있다면 많은 도움이 될 수 있으며 재정의를 피하기 위해 그 의미에 임의의 변형을 구성하지 않아도됩니다. 또는 더 나쁜 것은 'x2, x3, x4 등'...

Answer 12

C ++에서는 멤버가 이니셜 라이저를 사용하여 구성에서 초기화하는 것이 더 정상입니다.

이를 위해서는 멤버 변수의 이름과 다른 이름을 사용해야합니다.

그래서 내가 사용하더라도 Foo(int x) { this.x = x; } Java에서는 C ++에 있지 않을 것입니다.

실제 냄새는 초기 라이저의 사용 부족과 this -> x 그 자체.

누구든지 내가 이니셜 라이저와 함께 사용할 때 멤버 변수에 대한 생성자 인수를 위해 다른 이름을 사용하기 위해 내가 가진 모든 C ++ 상점에서 그것이 보편적 인 관행인지 아는 사람이 있습니까? 지원하지 않은 C ++ 컴파일러가 있었습니까?

Answer 13

오늘날 대부분의 IDE 편집자는 변수를 채색하여 로컬 변수의 클래스 멤버를 나타냅니다. 따라서, 가독성을 위해서는 접두사 또는 'this->'가 필요하지 않아야한다.

Answer 14

나는 "이것"을 사용하는 것을 좋아하지 않습니다. 왜냐하면 그것은 atavistic이기 때문입니다. Good Old C (CHERE C?)로 프로그래밍하고 OOP의 일부 특성을 모방하려는 경우 여러 멤버가있는 구조물을 만듭니다 (이는 객체의 속성과 유사 함) 세트를 만듭니다. 모든 사람들이 그들의 첫 번째 논증으로 해당 구조에 대한 포인터를 취하는 함수 (이들은 그 객체의 방법과 유사하다).

(이 typedef 구문이 맞지만 오랜 시간이 지났다고 생각합니다 ...)

typedef struct _myclass
{
   int _x;
} MyClass;

void f(MyClass this, int x)
{
   this->_x = x;
}

실제로 이전 C ++ 컴파일러는 실제로 코드를 위의 형태로 컴파일 한 다음 C 컴파일러로 전달한다고 생각합니다. 다시 말해 -C ++는 어느 정도까지 구문 설탕이었습니다. 그래서 왜 누군가가 C ++로 프로그래밍하고 싶어하고 코드에서 "this"를 명시 적으로 사용하고 싶은지 잘 모르겠습니다. 아마도 "Syntactic Nutrisweet"일 것입니다

Answer 15

이름 지정 규칙에 문제가있는 경우 Folowing과 같은 것을 사용할 수 있습니다.

class tea
{
public:
    int cup;
    int spoon;
    tea(int cups, int spoons);
};

또는

class tea
{
public:
    int cup;
    int spoon;
    tea(int drink, int sugar);
};

나는 당신이 아이디어를 가지고 있다고 생각합니다. 기본적으로 변수의 이름을 다르지만 논리적 의미에서 "동일"합니다. 도움이되기를 바랍니다.