필드 앞의 "this"키워드 및 c #의 메소드와 관련하여 현재 알려진 모범 사례는 무엇입니까?

같은 이름을 가진 변수와 필드를 구별 해야하는 경우가 아니라면 this.C #에서 필드 또는 멤버 액세스 앞에 두지 마십시오 . 나는 이것을 m_C ++에서 공통적으로 사용되었던 접두사 와 다르지 않다고 생각하고 실제로 그것이 멤버임을 지정해야한다면 클래스가 너무 크다고 생각합니다.

그러나 내 사무실에는 많은 사람들이 동의하지 않습니다.

현재 모범 사례는 무엇입니까 this.?

편집 : 명확히하기 위해 절대 사용하지 않아야 m_하며 this.절대적으로 필요한 경우 에만 사용 하십시오.

공용 또는 보호 된 필드를 참조 할 때 프레임 워크 디자인 지침 에 따르면

필드 이름에 접두사를 사용 하지 마십시오 .

예를 들어 m_접두사입니다.

따라서 thisMSDN에 설명 된대로 필드의 공개 노출은 키워드 사용에 적합합니다.

유사한 이름으로 숨겨진 구성원을 한정하려면 다음과 같이하십시오.

public Employee(string name, string alias) 
{
   this.name = name;
   this.alias = alias;
}

개인 필드를 참조 할 때 m_원하는 경우 사용할 수 있습니다 . 그러나 공공 장소에서는 모범 사례를 따르는 것이 좋습니다.

개인적으로 변수 이름에 밑줄을 좋아하지 않습니다. 또한 일관성을 유지하려고 노력합니다. 따라서 this.name = name;공개 / 비공개 시나리오 모두에서 작동하기에 좋은 경험 규칙입니다.

우리 팀에서는 주니어 클래스 개발자가 변수를보다 정확하게 / 즉시 식별 할 수 있도록 더 큰 클래스에서 this.또는 Me.객체 한정자 를 사용하는 표준을 채택 했습니다.

코드 측면에서 이것은 완전히 불필요한 영향이지만 결국 어쨌든 동일한 정확한 MISL 코드를 생성하기 때문에 아무것도 차단하지 않습니다. 우리는 일부 후배들과 함께 발견 한 즉각적인 문제를 해결했기 때문에 그것을 채택했습니다. 그 외에도 나는 그것을 포함시키는 것이 도움이되는 것으로 보지 않습니다.

StyleCop은 this.So 의 사용을 강제합니다. 모범 사례 (내가하는)로 간주하면 사용 this.이 모범 사례입니다.

당신이 채택하는 스타일은 당신과 자신의 코딩 표준에 달려 있습니다. 일관성을 유지하십시오. 일관성없이 사용하면 혼란이 생길 ​​수 있습니다.

내 추론은 사용 this.하면 인스턴스 속성을 참조한다는 사실을 불러내는 것입니다. 예를 들어, this.x = ...알고 있다면 알고 싶은 인스턴스를 변경하고 있다는 사실을 강조하는 데 도움이됩니다 . 또한 this.메소드가 항상 정적 일 수 없다는 것을 알 수 있습니다. 같은 규칙을 사용하면 m_이 작업을 수행 할 수 있지만 수동 m_으로 처리해야합니다. 정적으로 만들 거나 클래스 외부에서 값을 전달할 메서드를 리팩터링하는 경우 이름을 변경해야합니다. this그러면 컴파일러가 변경을 강제합니다.

this잘못 사용하면 코드가 컴파일되지 않고 m_수동으로 사용하고 도구를 활용하지 않기 때문에 간단히 사용하는 것이 더 쉽습니다 .

사용에 대한 좋은 점 중 하나는 m_작은 m인텔리전스 를 입력하자마자 모든 개인 변수 목록을 제공한다는 것입니다. 개인적으로 나는 그것이 더 유리하다고 생각합니다. 나는 또한 갈 것입니다 s_개인 정적과 c_비슷한 이유로 개인 상수. 헝가리어 표기법이지만 의미는 변수 이름에 유용한 의미를 추가하여 다른 프로그래머가 완전히 명확하지 않을 수있는 이름으로 그것에 대해 이야기 할 수 있기 때문입니다.

나는 멤버와 비 멤버 변수가 다르기 때문에 분명히 구별 할 수있는 방법에 동의하지 않으며 사람들이 뭔가를하지 않는 코드를 읽을 때 실제로 읽기가 더 어렵습니다. 사용하면 this.필요한 것보다 더 많은 보일러 플레이트처럼 느껴집니다. 그러나 실제로 개인 취향입니다. 잠시 동안 한 가지 방법으로 코딩하면 옳고 그 밖의 모든 것이 잘못되었다고 생각하게됩니다. 계획이 제정신인지 여부에 실제로 중요한 것은 팀의 모든 사람이 일관성이 있다는 것입니다.

this명시 적입니다. 놓칠 수없는 광학 신호입니다.

나는 항상 암시 적 코드보다 명시 적 코드를 선호합니다. 그래서 내가 this자주 사용 합니다. 최선의 방법이라고 생각합니다.

나는 항상 "this"를 사용합니다. 추론은 두 가지 간단한 사실에 근거합니다.

• 코드를 읽는 것이 코드를 쓰는 것보다 어렵습니다.
• 코드를 작성하는 것보다 코드를 더 자주 읽습니다.

"this"를 사용하면 글을 읽는 사람 (즉, 저자뿐만 아니라 구현의 세부 사항을 완전히 잊어 버린 후 6 개월 내에 저자를 포함 할 수 있음)에게 매우 명백하게됩니다. 여기서 다시 이야기하십시오. "m_"등은 컨벤션 일 뿐이며 다른 컨벤션과 마찬가지로 오용 (또는 전혀 사용되지 않음) 할 수 있습니다. 컴파일 시간이나 런타임에 "m _"/ etc를 적용 할 것은 없습니다. "this"는 더 강력합니다 : "m_"을 지역 변수에 넣을 수 있고 컴파일러는 불평하지 않습니다; "this"로는 그렇게 할 수 없습니다.

유감스럽게 생각되는 것이 있다면 "이것"의 사용이 언어 사양에서 필수가 아니라는 것이 유감입니다.

좋은 보너스로, 디버깅 할 때 "this"위에 마우스를 올려 놓거나 감시 할 수 있으며 다른 모든 클래스 멤버의 검사도 얻을 수 있습니다.

this키워드는 특히 같은 이름의 변수로 생성자 또는 방법이 있지만 동일한 유형을 가질 수 있습니다 할 때, 존재하는 두 변수를 구분하기 위해 특히 사용된다.

예:

public class Example {

    string reason;
    string cause;

    Example (string reason, string cause) {
        this.reason = reason;
        this.cause = cause;
    }

    //<Setter> if you want to explicitly write your onw
    public void setReason(stirng reason) {
        this.reason = reason;
    }
}

이것은 (예를 들어 this.reason = reason) 기본적으로 매개 변수의 값을 클래스의 변수에 할당합니다. this기본적으로 reason매개 변수 블록에서 클래스 를 가져옵니다 .

나는 또한 그것에 대해 한동안 궁금해했다. 자바 스크립트에서 광범위한 코딩을 한 후 this.C # 코드에서 더 자주 사용했습니다 (모호성을 피하기 위해 생성자 또는 유사한 메소드에서 거의 독점적으로 사용하기 전에). 그것은 약간의 추가 노력으로 코드를 조금 더 명확하게 만듭니다. 또한 접두사로 클래스 멤버 이름을 절단하지 않고 컨텍스트가 명확하거나 특히 복잡한 문장에서 멤버 '짧은 길'을 사용하는 것으로 되돌릴 수 있습니다. 난 그냥 추가 this.나는 더 이상 방법, 더 이상 인수 목록 또는 선언 많은 지역 변수를 가지고 있고이 코드가 약간의 추가 설명에서 이익이 있다고 생각하는 경우가 강제 될지라도,.

그러나 나는 개인적으로 m_접두사 스타일을 절대적으로 싫어합니다. 헝가리어가 아니기 때문에 밑줄이 타이핑하기가 어렵 기 때문에) 대안으로 생각하지 않습니다. 나는 그것이 지능에 관해서 강점을 가지고 있음을 인정할 것이지만, 멤버 변수의 처음 몇 글자를 기억할 수 없다면 클래스가 크다는 것을 다시 주장 할 수 있습니다.

나는 반원들에게 하나의 밑줄 접두사를 붙인다. _someVar;

왜? 처음에는 스택 변수가 아닌 멤버라는 것을 알고 있습니다. 한 눈에 편리합니다. 그리고 "this"키워드에 비해 혼란이 덜합니다.

this.필요하지 않거나 결과를 변경하지 않는 접두사 / 키워드 와 같은 것을 사용하는 것은 항상 주관적입니다. 그러나 나는 우리 대부분이 지역 변수와 필드를 구별하고 싶다는 데 동의 할 수 있다고 생각합니다. 어떤 사람들은 밑줄 접두어를 사용하고 (나는 추악하고 헝가리어 표기법을 사용합니다), 다른 사람들은 this.키워드를 사용합니다 . 나는 후자 중 하나입니다. 그것은 모두 가독성과 이해에 관한 것입니다. 더 명확하거나 읽기 쉬운 경우 조금 더 입력해도 괜찮습니다. 눈 깜짝 할 사이에 필드와 변수를 구별하고 싶습니다.

필자는 항상 이름이 비슷한 필드 myField와 매개 변수 이름 및 로컬 변수 이름이 비슷한 필드를 정의합니다 myField. 밑줄, 접두사 없음 this필드를 언급 하는 모든 곳에서 사용 합니다. 이런 식으로 접두어없이 로컬 변수 및 인수와 필드를 구별 할 수 있습니다. 물론 이와 같은 경우 this키워드가 필요합니다.

public Person(string firstName)
{
    this.firstName = firstName;
}

따라서 내 속성은 다음과 같습니다 (예, 항상 필드를 속성과 함께 배치하고 파일의 맨 위에는 관련이 없습니다) :

private string firstName;
public string FirstName
{
    get { return this.firstName; }
}

잘 읽습니다 : 이 이름을 반환하십시오 .

편집 : 내 대답은 분명히 대답이 아닙니다. 여기 편집 내용이 있습니다. Microsoft 코딩 지침은 다음과 같습니다.

2.6 명명

멤버 변수에 접두사를 사용하지 마십시오 ( , m , s_ 등). 로컬 변수와 멤버 변수를 구별하려면 "this"를 사용해야합니다. C #과 "Me"에서 VB.NET에서.

http://blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx 에서 찾을 수 있습니다.

따라서 적어도 MS에서는 명확한 지침이없는 것처럼 보이지만 다른 대답은 StyleCop이 그것을 지침으로 만든다고 진술합니다. 이것들에 대한 권한이 없으므로, 나는 당신이 당신 자신의 마음을 구성 하거나이 경우 팀에게 줄 것을 제안합니다. 그렇게 큰 문제는 아닙니다.

내 원래의 대답은 개인적으로 당신에게 동의하지만 어쩌면 두 가지 방법을 서로 비교하는 독해 시험이 가치가있을 것입니다. 그렇지 않으면 이러한 스타일의 것들이 혼란 스럽습니다.

필자의 견해 : 사람들은 불필요하게 코드 스타일을 복잡하게 만들고 있으며, 클래스 레벨 변수라는 것을 나타내야 할 경우 코드에 오래된 레시피 방법과 같은 다른 심각한 구조적 문제가있을 수 있습니다. 개인 변수를 클래스 상단에두면 끊임없이 위아래로 스크롤해야합니다.

이것은 "이것이 무엇인가"라는 규칙과 올바른 "이것이 무엇인가"명명 규칙 중 하나 인 저를 공격합니다. 간결함은 명시적인 것보다 선호되어야합니다. 이것은 동적 언어에 의해 자주 반복되는 교훈입니다. 우리는 모든 보풀이 필요하지 않습니다!

이. 종종 원치 않는 소음이 발생할 수 있습니다.

내 해결책은 다음과 같습니다.

• parameter_names_
• local_variables
• ANY_CONSTANT
• _private_members
• 비 개인 속성
• _NonPrivateProperty // 후원자
• privateProperty
• _privateProperty // 배커