언제 "this" 키워드를 사용합니까?[닫은]

Question

다른 사람들은 어떻게 사용하는지 궁금하네요 이것 예어.나는 생성자에서 이를 사용하는 경향이 있지만 다른 메서드의 클래스 전체에서 사용할 수도 있습니다.몇 가지 예:

생성자에서:

public Light(Vector v)
{
    this.dir = new Vector(v);
}

다른 곳

public void SomeMethod()
{
    Vector vec = new Vector();
    double d = (vec * vec) - (this.radius * this.radius);
}

Answer 1

여러 가지 용도가 있습니다. 이것 C#의 키워드.

1. 유사한 이름으로 숨겨진 회원의 자격을 얻으려면
2. 객체가 자신을 매개변수로 다른 메소드에 전달하도록 하려면
3. 객체가 메소드에서 자신을 반환하도록 하려면
4. 인덱서를 선언하려면
5. 확장 메서드를 선언하려면
6. 생성자 간에 매개변수를 전달하려면
7. 값 유형(구조체) 값을 내부적으로 재할당하려면.
8. 현재 인스턴스에서 확장 메서드를 호출하려면
9. 자신을 다른 유형으로 캐스팅하려면
10. 동일한 클래스에 정의된 생성자를 연결하려면

예를 들어 일반적인 명명 규칙을 따르고 필드(카멜 케이스) 대신 속성(파스칼 케이스)을 사용하여 지역 변수(또한 카멜 케이스)와의 충돌을 방지하는 등 범위에서 동일한 이름을 가진 멤버 및 로컬 변수를 갖지 않음으로써 첫 번째 사용을 피할 수 있습니다. 사례).C# 3.0에서는 필드를 다음을 사용하여 쉽게 속성으로 변환할 수 있습니다. 자동 구현 속성.

Answer 2

이 말이 비열하게 들린다는 뜻은 아니지만 상관없습니다.

진지하게.

중요한 사항을 살펴보십시오.당신의 프로젝트, 코드, 직업, 개인 생활.필드에 대한 액세스 자격을 부여하기 위해 "this" 키워드를 사용하는지 여부에 따라 성공 여부가 결정되지는 않습니다.이 키워드는 정시에 배송하는 데 도움이 되지 않습니다.버그가 줄어들지 않으며 코드 품질이나 유지 관리 가능성에 눈에 띄는 영향도 미치지 않습니다.급여가 인상되거나 사무실에서 보내는 시간이 줄어들지는 않습니다.

정말 스타일 문제일 뿐입니다."이것"이 마음에 드시면 사용하세요.그렇지 않다면하지 마십시오.올바른 의미를 얻기 위해 필요한 경우 이를 사용하십시오.사실, 모든 프로그래머는 자신만의 고유한 프로그래밍 스타일을 가지고 있습니다.그 스타일은 "가장 미학적으로 만족스러운 코드"가 어떤 모습이어야 하는지에 대한 특정 프로그래머의 생각을 반영합니다.정의에 따르면, 당신의 코드를 읽는 다른 프로그래머는 다른 프로그래밍 스타일을 갖게 될 것입니다.즉, 당신이 한 일이 상대방이 좋아하지 않거나 다르게 했을 일이 항상 있을 것이라는 뜻입니다.어떤 시점에서 어떤 사람은 당신의 코드를 읽고 뭔가에 대해 불평할 것입니다.

나는 그것에 대해 걱정하지 않을 것입니다.나는 단지 당신의 취향에 따라 코드가 가능한 한 심미적으로 만족스러운지 확인하고 싶습니다.10명의 프로그래머에게 코드 형식을 지정하는 방법을 묻는다면 약 15가지의 다른 의견을 듣게 될 것입니다.집중해야 할 더 좋은 점은 코드가 어떻게 구성되는지입니다.추상화된 것이 맞나요?사물에 의미 있는 이름을 골랐나요?코드 중복이 많나요?내용을 단순화할 수 있는 방법이 있나요?이러한 것들을 올바르게 수행하는 것은 귀하의 프로젝트, 코드, 직업 및 삶에 가장 긍정적인 영향을 미칠 것이라고 생각합니다.우연히도, 그것은 아마도 다른 사람이 가장 적게 불평하게 만들 것입니다.코드가 작동하고, 읽기 쉽고, 잘 고려되어 있다면 다른 사람은 필드를 초기화하는 방법을 면밀히 조사하지 않을 것입니다.그는 단지 당신의 코드를 사용하고 그 위대함에 감탄한 다음 다른 것으로 넘어갈 것입니다.

Answer 3

저는 꼭 필요한 경우, 즉 다른 변수가 다른 변수를 가리고 있을 때만 사용합니다.예를 들면 다음과 같습니다.

class Vector3
{
    float x;
    float y;
    float z;

    public Vector3(float x, float y, float z)
    {
        this.x = x;
        this.y = y;
        this.z = z;
    }

}

또는 Ryan Fox가 지적했듯이 이를 매개변수로 전달해야 하는 경우도 있습니다.(로컬 변수는 멤버 변수보다 우선합니다.)

Answer 4

개인적으로 저는 항상 사용하려고 노력하고 있어요 이것 멤버 변수를 참조할 때코드를 명확하게 하고 가독성을 높이는 데 도움이 됩니다.모호함이 없더라도 처음으로 내 코드를 읽는 사람은 그것을 알지 못하지만, 만약 그들이 본다면 이것 일관되게 사용하면 멤버 변수를 보고 있는지 여부를 알 수 있습니다.

Answer 5

필요하지 않더라도 인스턴스 변수를 참조할 때마다 이를 사용합니다.코드가 더 명확해지는 것 같아요.

Answer 6

나는 그것을 항상 사용하는 것이 "모범 사례"라고 말하는 모든 사람들을 믿을 수 없습니다.

다음과 같이 모호한 경우에는 "this"를 사용하세요. 코리의 예 또는 다음과 같이 객체를 매개변수로 전달해야 하는 경우 라이언의 예.범위 체인을 기반으로 변수를 확인할 수 있다는 것은 이를 통해 변수를 한정할 필요가 없을 만큼 충분히 명확해야 하기 때문에 이를 달리 사용할 이유가 없습니다.

편집하다:"this"에 대한 C# 문서는 제가 언급한 두 가지 외에 "this" 키워드에 대한 또 다른 용도를 나타냅니다. 인덱서 선언용

편집하다:@후안:허, 내 진술에 어떤 불일치도 보이지 않습니다. "this" 키워드를 사용하는 경우가 3번 있습니다(C# 설명서에 설명되어 있음). 필요 그것.섀도잉이 진행되지 않을 때 생성자의 변수 앞에 "this"를 붙이는 것은 단순히 키 입력 낭비이고 읽을 때 시간 낭비이므로 아무런 이점이 없습니다.

Answer 7

그럴때마다 사용해요 스타일캅 나에게 말한다. 스타일캅 순종해야합니다.바로 이거 야.

Answer 8

현재 객체에 대한 참조가 필요할 때마다.

특히 유용한 시나리오 중 하나는 개체가 함수를 호출하고 그 개체에 자신을 전달하려고 하는 경우입니다.

예:

void onChange()
{
    screen.draw(this);
}

Answer 9

나는 우리가 다루고 있는 것이 인스턴스 멤버인지 확인하기 위해 모든 곳에서 이를 사용하는 경향이 있습니다.

Answer 10

나는 모호함이 있을 수 있는 곳이라면 어디든 사용합니다(분명히).컴파일러의 모호함(이 경우에는 필요함)뿐만 아니라 코드를 보는 사람의 모호함도 마찬가지입니다.

Answer 11

this 키워드가 다소 드물게 사용되는 또 다른 경우는 구현 클래스 내에서 명시적인 인터페이스 구현을 호출해야 하는 경우입니다.다음은 고안된 예입니다.

class Example : ICloneable
{
    private void CallClone()
    {
        object clone = ((ICloneable)this).Clone();
    }

    object ICloneable.Clone()
    {
        throw new NotImplementedException();
    }
}

Answer 12

내가 그것을 사용하는 경우는 다음과 같습니다.

• 클래스 내에서 개인 메소드에 액세스(구별하기 위해)
• 현재 객체를 다른 메소드(또는 이벤트의 경우 전송자 객체)로 전달
• 확장 메서드를 만들 때 :D

비공개 필드 변수 이름 앞에 밑줄(_)을 붙이기 때문에 비공개 필드에는 이것을 사용하지 않습니다.

Answer 13

[C++]

나는 "필요할 때 사용하라" 여단에 동의합니다.불필요하게 코드를 장식하는 것 이것 당신이 그것을 잊어버렸을 때 컴파일러는 당신에게 경고하지 않을 것이기 때문에 좋은 생각이 아닙니다.이는 기대하는 사람들에게 잠재적인 혼란을 야기합니다. 이것 항상 거기에 있기 위해, 즉그들은 해야 할 것이다 생각하다 그것에 대해.

그럼 언제 사용하시겠어요?방금 임의의 코드를 둘러보고 다음 예제를 찾았습니다(이것이 맞는지 여부에 대해서는 판단하지 않습니다). 좋은 해야 할 일 또는 기타):

• "자신"을 함수에 전달합니다.
• 포인터 등에 "자신"을 할당합니다.
• 캐스팅, 즉위/아래 캐스팅(안전하거나 그렇지 않은 경우), 불변성 캐스팅 등
• 컴파일러는 명확성을 강제했습니다.

Answer 14

동일한 유형의 객체에 대한 참조를 허용하는 함수에서 이를 만들고 싶을 때 사용합니다. 완벽하게 맑은 내가 말하는 대상은 어디인지.

예를 들어

class AABB
{
  // ... members
  bool intersects( AABB other )
  {
    return other.left() < this->right() &&
           this->left() < other.right() &&

           // +y increases going down
           other.top() < this->bottom() &&
           this->top() < other.bottom() ;
  }
} ;

(대)

class AABB
{
  bool intersects( AABB other )
  {
    return other.left() < right() &&
           left() < other.right() &&

           // +y increases going down
           other.top() < bottom() &&
           top() < other.bottom() ;
  }
} ;

AABB가 하는 일을 한눈에 right() 인용하다?그만큼 this 약간의 정화기를 추가합니다.

Answer 15

Jakub Šturc의 답변에서 생성자 간 데이터 전달에 관한 그의 #5 답변에는 약간의 설명이 필요할 수 있습니다.이는 생성자를 오버로드하는 경우이며 다음을 사용하는 경우 중 하나입니다. this 필수입니다.다음 예제에서는 기본 매개변수를 사용하여 매개변수 없는 생성자에서 매개변수화된 생성자를 호출할 수 있습니다.

class MyClass {
    private int _x
    public MyClass() : this(5) {}
    public MyClass(int v) { _x = v;}
}

나는 이것이 때때로 특히 유용한 기능이라는 것을 알았습니다.

Answer 16

항상 사용해야 하며 저는 이를 개인 필드와 매개변수를 구별하는 데 사용합니다. 왜냐하면 우리의 명명 규칙에 따르면 멤버 및 매개변수 이름에 접두사를 사용하지 않는다고 명시되어 있기 때문입니다(그리고 이는 인터넷에서 찾은 정보를 기반으로 하기 때문에 모범 사례))

Answer 17

Visual C++에서 자유롭게 사용하는 습관이 생겼습니다. 그렇게 하면 IntelliSense가 실행되기 때문에 '>' 키를 누르면 게으릅니다.(그리고 오타가 발생하기 쉬움)

하지만 전역 함수가 아닌 멤버 함수를 호출하는 것을 확인하는 것이 편리하기 때문에 계속해서 사용했습니다.

Answer 18

나는 필드에 _를 밑줄로 표시하는 경향이 있으므로 실제로 이것을 사용할 필요는 없습니다.또한 R#은 어쨌든 그것들을 리팩터링하는 경향이 있습니다.

Answer 19

저는 거의 그냥 사용해요 이것 동일한 유형 내부에서 유형 속성을 참조할 때.다른 사용자가 언급했듯이 로컬 필드에도 밑줄을 표시하여 별도의 작업 없이도 눈에 띕니다. 이것.

Answer 20

단일 인수 다형성으로 인해 한쪽 메소드에 넣어야 하는 대칭 연산을 제외하고는 필요할 때만 사용합니다.

boolean sameValue (SomeNum other) {
   return this.importantValue == other.importantValue;
} 

Answer 21

[C++]

이것 대부분의 경우 다음과 같은 이상한(의도하지 않았거나 위험하거나 프로그램에 대한 시간 낭비) 것을 확인하고 방지해야 하는 할당 연산자에 사용됩니다.

A a;
a = a;

할당 연산자는 다음과 같이 작성됩니다.

A& A::operator=(const A& a) {
    if (this == &a) return *this;

    // we know both sides of the = operator are different, do something...

    return *this;
}

Answer 22

this C++ 컴파일러에서

C++ 컴파일러는 기호를 즉시 찾지 못하면 자동으로 기호를 찾습니다.때로는 대부분의 경우 다음과 같은 경우가 좋습니다.

• 자식 클래스에 오버로드하지 않은 경우 어머니 클래스의 메서드를 사용합니다.
• 한 유형의 값을 다른 유형으로 승격

하지만 가끔은, 컴파일러가 추측하는 것을 원하지 않을 뿐입니다.컴파일러가 다른 기호가 아닌 올바른 기호를 선택하기를 원합니다.

나를 위한, 그 때는 메서드 내에서 멤버 메서드나 멤버 변수에 액세스하려는 경우입니다.내가 썼다는 이유로 임의의 기호가 선택되는 것을 원하지 않습니다. printf 대신에 print. this->printf 컴파일되지 않았을 것입니다.

요점은 C 레거시 라이브러리(§), 수년 전에 작성된 레거시 코드(§§) 또는 복사/붙여넣기가 더 이상 사용되지 않지만 여전히 활성화된 기능인 언어에서 발생할 수 있는 모든 일이 때로는 컴파일러에게 재생되지 않도록 지시한다는 것입니다. 지혜는 좋은 생각이다.

이것이 내가 사용하는 이유이다 this.

(§) 그것은 여전히 ​​나에게 미스터리이지만 이제 소스에 <windows.h> 헤더를 포함한다는 사실이 모든 레거시 C 라이브러리 기호가 전역 네임스페이스를 오염시키는 이유인지 궁금합니다.

(§§) "헤더를 포함해야 하지만 이 헤더를 포함하면 일반 이름을 가진 멍청한 매크로를 사용하기 때문에 코드가 손상된다는 점"을 깨닫는 것이 그 중 하나입니다. 러시아어 룰렛 코더의 삶의 순간들

Answer 23

'이것.' 많은 회원이있는 '이'수업에서 회원을 찾는 데 도움이됩니다 (보통 상속 체인으로 인해).

Ctrl+Space를 누르는 것은 유형도 포함하기 때문에 도움이 되지 않습니다.어디서 '이거' 회원 만 포함합니다.

나는 보통 내가 원하는 것이 있으면 삭제합니다.하지만 이건 그냥 돌파하는 내 스타일이에요.

스타일 측면에서 볼 때, 당신이 고독한 사람이라면 - 당신이 결정합니다.회사에서 일하는 경우 회사 정책을 준수하십시오(소스 제어의 내용을 살펴보고 다른 사람들이 무엇을 하고 있는지 확인하십시오).회원 자격을 부여하기 위해 이를 사용하는 측면에서는 옳지도 그르지도 않습니다.유일한 잘못된 점은 불일치입니다. 이것이 스타일의 황금률입니다.잔소리하는 다른 사람들은 그대로 두십시오.대신에 실제 코딩 문제와 당연히 코딩에 대해 숙고하는 데 시간을 투자하십시오.

Answer 24

내가 작업하는 코딩 표준에 따라 다릅니다.인스턴스 변수를 표시하기 위해 _를 사용하는 경우 "this"는 중복됩니다._를 사용하지 않는다면 인스턴스 변수를 표시하기 위해 이것을 사용하는 경향이 있습니다.

Answer 25

호출하는 데 사용합니다. 인텔리센스 처럼 존맥지, 하지만 작업이 끝나면 돌아가서 "this->"를 삭제하겠습니다.저는 멤버 변수 앞에 "m_"을 붙이는 Microsoft 규칙을 따르므로 문서로 남겨두는 것은 중복될 것입니다.

Answer 26

1 - 일반적인 Java setter 관용구:

 public void setFoo(int foo) {
     this.foo = foo;
 }

2 - 이 개체를 매개변수로 사용하여 함수를 호출하는 경우

notifier.addListener(this);

Answer 27

나는 가능할 때마다 그것을 사용합니다.나는 그것이 코드를 더 읽기 쉽게 만들고, 더 읽기 쉬운 코드는 버그가 적고 유지 관리 가능성이 높다고 믿습니다.

Answer 28

동일한 코드 기반으로 작업하는 개발자가 많은 경우 몇 가지 코드 지침/규칙이 필요합니다.제가 일하는 곳에서는 필드, 속성 및 이벤트에 'this'를 사용하기로 결정했습니다.

나에게는 이렇게 하는 것이 합리적입니다. 이렇게 하면 클래스 변수와 메서드 변수를 구별할 때 코드를 더 쉽게 읽을 수 있습니다.

Answer 29

C++에서 아직 언급되지 않은 한 가지 용도가 있는데, 그것은 자신의 개체를 참조하거나 수신된 변수에서 멤버를 명확하게 하는 것이 아닙니다.

당신이 사용할 수있는 this 다른 템플릿에서 상속되는 템플릿 클래스 내에서 비종속적 이름을 인수 종속적 이름으로 변환합니다.

template <typename T>
struct base {
   void f() {}
};

template <typename T>
struct derived : public base<T>
{
   void test() {
      //f(); // [1] error
      base<T>::f(); // quite verbose if there is more than one argument, but valid
      this->f(); // f is now an argument dependent symbol
   }
}

템플릿은 2단계 메커니즘으로 컴파일됩니다.첫 번째 단계에서는 인수가 아닌 종속 이름만 확인 및 검사되는 반면 종속 이름은 템플릿 인수를 실제로 대체하지 않고 일관성만 확인합니다.

해당 단계에서 실제로 유형을 대체하지 않으면 컴파일러는 무엇인지에 대한 정보가 거의 없습니다. base<T> 될 수 있습니다(기본 템플릿을 특수화하면 완전히 다른 유형, 심지어 정의되지 않은 유형으로도 바뀔 수 있음). 그래서 단지 유형이라고 가정합니다.이 단계에서는 비의존 호출 f 프로그래머에게 자연스러운 것처럼 보이는 것은 컴파일러가 구성원으로 찾아야 하는 기호입니다. derived 또는 둘러싸는 네임스페이스에서(예제에서는 발생하지 않음) 불평을 표시합니다.

해결책은 비종속적 이름을 바꾸는 것입니다. f 종속 이름으로.이는 구현된 유형을 명시적으로 지정하여 몇 가지 방법으로 수행할 수 있습니다(base<T>::f --추가 base<T> 기호가 다음에 의존하게 만듭니다. T 그리고 컴파일러는 그것이 존재할 것이라고 가정하고 인수 대체 후 두 번째 패스에 대한 실제 검사를 연기합니다.

두 개 이상의 인수나 긴 이름이 있는 템플릿에서 상속하는 경우 두 번째 방법은 훨씬 더 많은 분류기를 추가하는 것입니다. this-> 기호 앞에.구현 중인 템플릿 클래스는 인수에 따라 달라지므로(다음에서 상속됩니다.) base<T>) this-> 인수에 따라 다르며 동일한 결과를 얻습니다. this->f 템플릿 매개변수 대체 후 두 번째 라운드에서 확인됩니다.

Answer 30

꼭 필요한 경우가 아니면 "this"를 사용하면 안 됩니다.

불필요한 장황함과 관련된 처벌이 있습니다.더 이상 필요하지 않은 딱 필요한 만큼의 코드를 위해 노력해야 합니다.