Java에서`this` 키워드를 사용할 때 허용되는 스타일은 무엇입니까?

나는 파이썬이나 자바 스크립트 (그리고 객체 지향이 아닌 다른 언어)와 같은 언어에서 왔으며 Java에 대한 실무 지식을 향상시키기 위해 노력하고 있습니다.

항상 this현재 인스턴스 속성 앞에 추가하는 것은 나쁜 습관으로 간주 됩니까? 글쓰기가 더 자연 스럽습니다

...
private String foo;

public void printFoo() {
    System.out.println(this.foo);
}
...

...보다

...
private String foo;

public void printFoo() {
    System.out.println(foo);
}
...

인스턴스 속성을 로컬 변수와 구별하는 데 도움이됩니다.

물론 Javascript와 같은 언어에서는 더 this많은 함수 중첩을 가질 수 있으므로 지역 변수가 더 큰 범위에서 나오므로 항상 사용하는 것이 더 좋습니다 . Java에서는 이해하는 한 내부 클래스를 제외하고 이와 같은 중첩이 불가능하므로 큰 문제는 아닙니다.

어쨌든 나는을 사용하는 것을 선호합니다 this. 이상하고 관용적이지 않습니까?

대부분의 IDE에서 알고 싶다면 변수 위에 마우스를 갖다 대면됩니다. 또한 인스턴스 메소드에서 작업하는 경우 관련된 모든 변수를 알아야합니다. 너무 많거나 이름이 충돌하면 리팩토링해야합니다.

정말 중복됩니다.

사용하는 것을 선호합니다 this. 동일한 방식으로 로컬 및 인스턴스 변수에 색상을 지정하는 다양한 편집기에서 코드를보다 쉽게 ​​읽을 수 있습니다. 또한 코드 검토와 같은 동안 인쇄 된 페이지에서 코드를 쉽게 읽을 수 있습니다. 또한 다른 개발자에게 변수의 범위와 관련하여 상당히 강력한 알림입니다.

그러나 이에 반대되는 주장이 있습니다. 최신 IDE에서는 변수 위로 마우스를 가져 가거나 트리와 같은 구조로 변수의 범위를 확인할 수 있습니다. 변수의 범위에 따라 변수의 색상 및 / 또는 글꼴을 변경할 수도 있습니다 (인쇄 할 때 변수의 범위가 무엇인지 분명한 방식으로도).

나는 ChrisF의 마지막 문장 이 끝났다고 믿습니다 .

내가 지속적으로 'this'를 사용하는 한 곳은 세터 및 생성자입니다.

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

그 외에는 추가해야한다고 생각하지 않습니다. 메소드의 본문을 읽을 때 매개 변수와 지역 변수가 있으며 추적하기가 쉽습니다 (IDE의 도움이 없어도). 또한 지역 및 필드는 특성이 다른 경향이 있습니다 (오브젝트 상태 대 임시 스토리지 또는 매개 변수).

변수와 필드에 대해 혼동이있는 경우, 방법에 너무 많은 변수 / 매개 변수가 있고 너무 길고 복잡하며 단순화되어야 함을 의미합니다.

'this'를 사용하여 필드에 태그를 지정하는 경우 규칙을 항상 엄격하게 준수하는 것이 좋습니다. 'this'가 없다고 가정하면 시작하기가 쉽지 않습니다.

편집 : 또한 equals, clone 또는 동일한 객체 유형의 'that'매개 변수가있는 항목에서 이것을 사용합니다.

public boolean isSame(MyClass that) {
    return this.uuid().equals(that.uuid());
}

논쟁의 여지가 있습니다.

C #을 Java와 매우 유사한 구문 및 구조를 갖기 때문에 C #을 비유로 사용하면 C # StyleCop에는 추가를 요구하는 기본 규칙이 this있지만 ReSharper에는 기본 규칙이 this있습니다. 제거되었습니다.

따라서 하나의 도구를 사용하는 경우 도구를 추가하지만 다른 도구를 사용하는 경우 도구를 제거합니다. 두 도구를 모두 사용하는 경우 규칙 중 하나를 선택하고 비활성화해야합니다.

그러나 규칙이 의미하는 바는 사용량이 일정하다는 것입니다. 이는 아마도 가장 중요한 것입니다.

이것을 항상 현재 인스턴스 속성 앞에 추가하는 것은 나쁜 습관으로 간주됩니까?

그렇습니다. 어떤 사람들은 그렇지 않습니다.

thisJava 및 C #의 프로젝트에서 키워드를 좋아하고 사용 합니다. IDE가 항상 매개 변수와 필드를 다른 색상으로 강조한다고 주장 할 수 있지만 IDE에서는 항상 작동하지는 않습니다. 메모장에서 많은 병합 / 확산 / 빠른 변경을 수행해야합니다 ./ 전자 메일에서 일부 코드 스 니펫 확인 . 그것은의 방법 , 예를 들어 몇 가지 가능한 동시성 문제를 검토 - 나 인스턴스의 상태가 변경되는 첫 번째 모습에서 발견하기가 쉽다.

이것을 사용해야 할 경우 너무 긴 메소드 또는 너무 많은 클래스를 시도하는 클래스 또는 둘 다가 있다고 생각합니다.

메소드는 코드의 몇 줄을 넘지 않아야합니다. 하나 또는 두 개의 로컬 변수를 사용하여 무엇이 쉬운 지 결정하십시오. 대부분의 diff 도구의 3 줄 컨텍스트에서만 가능합니다. 메서드가 너무 길고 클래스에 너무 많은 책임이있는 경우 (종종 너무 많은 필드를 의미) 대신 솔루션을 분할하는 것이 해결책입니다.

"this"는 코드를 복잡하게 만든다고 생각합니다. 특히 로컬 매개 변수 / 로컬 변수 / 필드의 색상을 다르게하는 최신 IDE의 경우.

나는 당신 이 이것으로 당신의 자신의 질문에 대답했다고 생각합니다 :

글쓰기가 더 자연 스럽습니다

... this.foo ...

...보다

... foo ...

인스턴스 속성을 로컬 변수와 구별하는 데 도움이됩니다.

당신이 사용하는 더 편안 경우 this.모든 수단이 일을 사용 그때까지, 자바와 실무 지식을 향상시키는 동시에 ( 나는 방법, 친숙한에, 생각 파이썬 자체가 당신이 관련되어 있음 ).

문제는 사람들이을 사용하거나 사용하지 않는 것에 대해 확실하고 적절한 논쟁을 할 것이지만 this.여전히 논쟁의 여지가있는 것 같습니다.

• 이 변수의 목적이 취소하게 대 는 각 변수가 무엇인지 분명하지 않다 경우 코드를 다시 작성해야한다;
• this.당신이 IDE에서 전체 하루를 보낼 경우 중복 대 내가 강조없는 구문 비교기를 사용하여 다른 버전에 코드 리뷰 및 메이크업의 차이점을 수행;
• 타이핑 this.을 하지 않으면 중요한 밀리 초의 생산성을 얻을 수 있습니다. vs 키를 누르면 this.비용을 지불 하고 추가하는 것이 임금 인상과 같습니다.
• 등

그러나 결론은 하루가 끝날 때에도 여전히 개인의 취향과 업무 환경으로 돌아갑니다 .

일반적으로 이것을 추가 할 필요는 없습니다. 나는 그 자체가 나쁜 습관이라고 생각하지 않지만, 이것을 많이 사용 하는 것은 내가 본 대부분의 Java 코드베이스에서 비정상으로 간주 될 것입니다.

그러나 나는 두 가지 구체적인 상황에서 가치가 있다고 생각합니다.

로컬 매개 변수 재정의 -때로는 같은 이름의 매개 변수 / 로컬 변수 대신 인스턴스 변수를 사용하도록 지정해야 할 때가 있습니다. 매개 변수 이름을 초기화하는 데 사용되는 인스턴스 변수의 내부 이름과 일치시키려는 생성자에서 매우 일반적입니다.

class MyObject {
  int value;

  public MyObject(int value) {
    this.value=value;
  }
}

같은 클래스의 다른 인스턴스를 처리 할 때 -참조하는 클래스의 인스턴스를 명시 적으로 나타내는 것이 더 명확하고 이해하기 쉽다고 생각합니다.

class MyObject {
  int value;
  ....

  public MyObject add(MyObject other) {
    return new MyObject( this.value + other.value )
  }
}