티스토리 뷰
C # 에서이 키워드 는 여러 가지 용도로 사용 됩니다.
- 유사한 이름으로 숨겨진 회원 자격을 얻으려면
- 개체가 다른 메서드에 매개 변수로 자신을 전달하도록하려면
- 객체가 메서드에서 자신을 반환하도록하려면
- 인덱서를 선언하려면
- 확장 메서드를 선언하려면
- 생성자간에 매개 변수를 전달하려면
- 내부적으로 값 유형 (구조체) 값을 재 할당합니다 .
- 현재 인스턴스에서 확장 메서드를 호출하려면
- 자신을 다른 유형으로 캐스팅하려면
- 동일한 클래스에 정의 된 생성자를 연결하려면
예를 들어 공통 명명 규칙을 따르고 필드 (낙타 사례) 대신 속성 (파스칼 사례)을 사용하여 지역 변수 (낙타)와의 충돌을 방지하는 것과 같이 범위에 동일한 이름을 가진 구성원 및 지역 변수를 사용하지 않음으로써 첫 번째 사용을 피할 수 있습니다. 케이스). C # 3.0에서는 자동 구현 속성 을 사용하여 필드를 속성으로 쉽게 변환 할 수 있습니다 .
-------------------비정상적으로 들린다는 뜻은 아니지만 중요하지 않습니다.
진지하게.
프로젝트, 코드, 직업, 개인 생활 등 중요한 사항을 살펴보십시오. 그들 중 누구도 필드에 대한 액세스를 제한하기 위해 "this"키워드를 사용하는지 여부에 따라 성공하지 못할 것입니다. 이 키워드는 정시에 배송하는 데 도움이되지 않습니다. 버그를 줄이지 않을 것이며 코드 품질이나 유지 관리성에 눈에 띄는 영향을 미치지 않을 것입니다. 인상을 주거나 사무실에서 보내는 시간을 줄일 수는 없습니다.
정말 스타일 문제 일뿐입니다. "이"가 마음에 들면 사용하십시오. 그렇지 않다면하지 마십시오. 올바른 의미를 얻기 위해 필요한 경우 사용하십시오. 사실, 모든 프로그래머는 고유 한 프로그래밍 스타일을 가지고 있습니다. 이 스타일은 "가장 미적으로 만족스러운 코드"가 어떻게 생겼는지에 대한 특정 프로그래머의 개념을 반영합니다. 정의에 따라 코드를 읽는 다른 프로그래머는 다른 프로그래밍 스타일을 갖게됩니다. 즉, 상대방이 좋아하지 않거나 다르게했을 일이 항상있을 것입니다. 어떤 시점에서 어떤 사람이 당신의 코드를 읽고 무언가에 대해 불평 할 것입니다.
나는 그것에 대해 걱정하지 않을 것입니다. 나는 코드가 당신 자신의 취향에 따라 가능한 한 미학적으로 만족 스럽도록 만들 것입니다. 10 명의 프로그래머에게 코드 형식을 지정하는 방법을 묻는다면 약 15 개의 다른 의견을 얻을 수 있습니다. 집중해야 할 더 좋은 점은 코드가 어떻게 팩터링되는지입니다. 추상화 된 것이 맞습니까? 의미있는 이름을 골랐나요? 코드 중복이 많습니까? 항목을 단순화 할 수있는 방법이 있습니까? 제 생각에 이러한 일을 올바르게하는 것은 프로젝트, 코드, 직업 및 삶에 가장 큰 긍정적 인 영향을 미칠 것입니다. 우연히도 다른 사람이 최소한으로 불평하게 만들 것입니다. 코드가 작동하고 읽기 쉽고 요소가 잘 잡혀 있다면 다른 사람은 필드를 초기화하는 방법을 면밀히 조사하지 않을 것입니다. 그는 단지 당신의 코드를 사용하고 그 위대함에 감탄할 것입니다.
-------------------나는 절대적으로 필요할 때, 즉 다른 변수가 다른 변수를 섀도 잉 할 때만 사용합니다. 여기와 같은 :
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가 지적했듯이 이것을 매개 변수로 전달해야 할 때. (지역 변수는 멤버 변수보다 우선합니다.)
-------------------개인적 으로 멤버 변수를 참조 할 때 항상 이것을 사용하려고 합니다. 코드를 명확하게하고 더 읽기 쉽게 만들 수 있습니다. 모호하지 않더라도 처음으로 내 코드를 읽는 사람은 그것을 알지 못하지만 이것이 일관되게 사용되는 것을 보면 멤버 변수를보고 있는지 여부를 알 수 있습니다.
-------------------필요하지 않더라도 인스턴스 변수를 참조 할 때마다 사용합니다. 나는 그것이 코드를 더 명확하게 만든다고 생각한다.
-------------------나는 그것을 항상 사용하는 것이 "모범 사례"라고 말하는 모든 사람들이 믿을 수 없다.
Corey의 예 에서와 같이 모호함이 있거나 Ryan의 예 에서와 같이 개체를 매개 변수로 전달해야하는 경우 "this"를 사용 합니다 . 스코프 체인을 기반으로 변수를 해결할 수 있다는 것은 변수를 한정하는 것이 불필요 할만큼 명확해야하므로 다른 방법으로 사용할 이유가 없습니다.
편집 : "this"에 대한 C # 문서는 내가 언급 한 두 가지 외에 "this"키워드에 대해 인덱서를 선언 하는 데 한 번 더 사용함을 나타냅니다.
편집 : @Juan : 허, 나는 내 진술에서 어떤 불일치를 보지 않는다-내가 "this"키워드 (C # 문서에 설명 된대로)를 사용할 때 3 개의 인스턴스가 있고 실제로 그것을 필요로 할 때이다. 섀도 잉이 진행되지 않을 때 생성자의 변수 앞에 "this"를 붙이는 것은 단순히 키 입력을 낭비하고 그것을 읽을 때 시간을 낭비하는 것입니다. 그것은 아무런 이점도 제공하지 않습니다.
-------------------StyleCop이 지시 할 때마다 사용합니다 . StyleCop 을 준수해야합니다. 어 그래.
-------------------현재 개체에 대한 참조가 필요할 때마다.
특히 편리한 시나리오 중 하나는 객체가 함수를 호출하고 자신을 전달하려는 경우입니다.
예:
void onChange()
{
screen.draw(this);
}
나는 우리가 다루고있는 것이 인스턴스 멤버라는 것을 확실히하기 위해 어디에서나 사용하는 경향이 있습니다.
-------------------모호함이있을 수있는 모든 곳에서 사용합니다 (분명히). 컴파일러의 모호성 (이 경우에는 필요함)뿐만 아니라 코드를 보는 사람에 대한 모호성도 있습니다.
-------------------this 키워드의 또 다른 드문 사용은 구현 클래스 내에서 명시 적 인터페이스 구현을 호출해야 할 때입니다. 다음은 인위적인 예입니다.
class Example : ICloneable
{
private void CallClone()
{
object clone = ((ICloneable)this).Clone();
}
object ICloneable.Clone()
{
throw new NotImplementedException();
}
}
사용하는 경우는 다음과 같습니다.
- 클래스 내에서 개인 메서드에 액세스 (구분하기 위해)
- 현재 객체를 다른 메소드에 전달 (또는 이벤트의 경우 발신자 객체로)
- 확장 메서드를 만들 때 : D
개인 필드 변수 이름에 밑줄 (_)을 접두사로 사용하기 때문에 개인 필드에 사용하지 않습니다.
-------------------[C ++]
나는 "필요할 때 사용"여단에 동의합니다. 불필요하게 코드를 장식 이 것은 당신이 그것을 할 것을 잊지 때 컴파일러가 경고를하지 않기 때문에 좋은 생각이 아니다. 기대하는 사람들이 소개하고 잠재적 인 혼란 이 항상로는, 즉, 그들은해야합니다 생각 그것에 대해.
그렇다면 언제 사용 하시겠습니까? 나는 방금 임의의 코드를 둘러보고 다음 예제를 찾았습니다 (이것들이 좋은 일인지 아닌지 판단 하지 않습니다).
- "자신"을 함수에 전달합니다.
- 포인터 또는 이와 유사한 것에 "자신"을 할당합니다.
- 캐스팅, 즉 업 / 다운 캐스팅 (안전 또는 기타), 불변성 캐스팅 등
- 컴파일러 강제 명확성.
항상 사용해야합니다. 개인 필드와 매개 변수를 구별하는 데 사용합니다 (이름 지정 규칙에 멤버 및 매개 변수 이름에 접두사를 사용하지 않는다고 명시되어 있기 때문에 인터넷에서 찾은 정보를 기반으로하기 때문에 모범 사례))
-------------------동일한 유형의 객체에 대한 참조를 허용하는 함수에서 어떤 객체를 어디에서 참조하는지 완벽하게 명확하게 만들고 싶을 때 사용합니다 .
예를 들면
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() ;
}
} ;
(vs)
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정화기의 비트를 추가합니다.
Jakub Šturc의 답변에서 작성자 간의 데이터 전달에 대한 # 5는 아마도 약간의 설명을 사용할 수있을 것입니다. 이는 생성자 오버로딩에 있으며 사용 this이 필수 인 경우입니다. 다음 예제에서는 기본 매개 변수를 사용하여 매개 변수없는 생성자에서 매개 변수화 된 생성자를 호출 할 수 있습니다.
class MyClass {
private int _x
public MyClass() : this(5) {}
public MyClass(int v) { _x = v;}
}
나는 이것이 때때로 특히 유용한 기능이라는 것을 발견했습니다.
-------------------Visual C ++에서 자유롭게 사용하는 습관이 생겼습니다. 그렇게하면 IntelliSense가 '>'키를 눌렀고 게으 르기 때문입니다. (오타가 발생하기 쉽습니다)
그러나 나는 그것을 계속해서 사용하고있다. 내가 글로벌 함수가 아닌 멤버 함수를 호출하고 있다는 것을 알면 편리하기 때문이다.
-------------------나는 _로 필드에 밑줄을 긋는 경향이 있으므로 이것을 사용할 필요가 없습니다. 또한 R #은 어쨌든 그들을 리팩토링하는 경향이 있습니다 ...
-------------------동일한 유형 내부에서 유형 속성을 참조 할 때만 이것을 사용 합니다. 다른 사용자가 언급했듯이 필자는 로컬 필드에 밑줄을 표시 하여이 필요없이 눈에 띄도록 합니다 .
-------------------단일 인수 다형성으로 인해 한쪽 메서드에 넣어야하는 대칭 작업을 제외하고 필요한 경우에만 사용합니다.
boolean sameValue (SomeNum other) {
return this.importantValue == other.importantValue;
}
[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;
}
this C ++ 컴파일러에서
C ++ 컴파일러는 심볼을 즉시 찾지 못하면 조용히 검색합니다. 때로는 대부분의 경우 좋습니다.
- 자식 클래스에서 오버로드하지 않은 경우 어머니 클래스의 메서드를 사용합니다.
- 유형의 값을 다른 유형으로 승격
그러나 때로는 컴파일러가 추측하는 것을 원하지 않습니다. 컴파일러가 다른 기호가 아닌 올바른 기호를 선택하기를 원합니다.
나를 위해 , 그 시간은 메서드 내에서 멤버 메서드 또는 멤버 변수에 액세스하고 싶을 때입니다. printf대신에 썼다는 이유만으로 임의의 기호가 선택되는 것을 원하지 않습니다 print. this->printf컴파일하지 않았을 것입니다.
요점은 C 레거시 라이브러리 (§), 몇 년 전에 작성된 레거시 코드 (§§) 또는 복사 / 붙여 넣기가 구식이지만 여전히 활성화 된 기능인 언어에서 발생할 수있는 모든 일, 때로는 컴파일러에게 재생하지 않도록 지시하는 것입니다. 지혜는 좋은 생각입니다.
이것이 내가 사용하는 이유 this입니다.
(§) 여전히 나에게는 일종의 수수께끼이지만 소스에 <windows.h> 헤더를 포함한다는 사실이 모든 레거시 C 라이브러리 기호가 전역 네임 스페이스를 오염시키는 이유인지 궁금합니다.
(§§) "헤더를 포함해야하지만이 헤더를 포함하면 일반 이름을 가진 멍청한 매크로를 사용하기 때문에 코드가 손상 될 것입니다."라는 사실을 깨닫는 것은 코더의 삶의 러시아 룰렛 순간 중 하나입니다.
-------------------'이.' 많은 멤버가있는 'this'클래스에서 멤버를 찾는 데 도움이됩니다 (일반적으로 깊은 상속 체인으로 인해).
CTRL + Space를 눌러도 유형도 포함되기 때문에 도움이되지 않습니다. 어디에- '이.' 회원 만 포함됩니다.
나는 보통 내가 원하는 것이 있으면 삭제하지만 이것은 단지 내 스타일을 깨는 것입니다.
스타일 측면에서, 당신이 외로운 레인저라면-당신이 결정합니다. 회사에서 일하는 경우 회사 정책을 고수하십시오 (소스 제어의 항목을보고 다른 사람들이 무엇을하고 있는지 확인하십시오). 회원 자격을 얻기 위해 사용하는 측면에서 옳거나 그름은 없습니다. 유일한 잘못된 것은 일관성이 없다는 것입니다. 그것은 스타일의 황금률입니다. nit-picking 다른 사람은 남겨주세요. 대신 실제 코딩 문제를 숙고하고 코딩하는 데 시간을 할애하십시오.
-------------------할 수있을 때마다 사용합니다. 나는 그것이 코드를 더 읽기 쉽게 만들고, 더 읽기 쉬운 코드는 더 적은 버그와 더 많은 유지 보수성과 같다고 생각합니다.
-------------------동일한 코드베이스에서 작업하는 개발자가 많으면 코드 지침 / 규칙이 필요합니다. 내가 일하는 곳에서는 필드, 속성 및 이벤트에 'this'를 사용하기를 원했습니다.
나에게는 이렇게하는 것이 합리적이며, 클래스 변수와 메서드 변수를 구분할 때 코드를 더 쉽게 읽을 수 있습니다.
-------------------내가 작업하고있는 코딩 표준에 따라 다릅니다. _를 사용하여 인스턴스 변수를 나타내면 "this"가 중복됩니다. _를 사용하지 않으면 인스턴스 변수를 나타내는 데 사용하는 경향이 있습니다.
-------------------JohnMcG 처럼 Intellisense 를 호출하는 데 사용 하지만 완료되면 돌아가서 "this->"를 지 웁니다. 멤버 변수 앞에 "m_"을 붙이는 Microsoft 규칙을 따르므로 문서로 남겨두면 중복됩니다.
-------------------1-공통 Java setter 관용구 :
public void setFoo(int foo) {
this.foo = foo;
}
2-이 객체를 매개 변수로 사용하여 함수를 호출 할 때
notifier.addListener(this);
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템플릿 매개 변수 대체 한 후, 두 번째 라운드에서 확인됩니다.
꼭 필요한 경우가 아니면 "this"를 사용해서는 안됩니다.
불필요한 자세한 내용과 관련된 벌칙이 있습니다. 더 이상 필요하지 않은 코드를 위해 노력해야합니다.
출처
https://stackoverflow.com/questions/180199