Golang에서“this”사용

Golang이 여기 에있는 스타일 가이드에 가장 가까운 것은 수신자 이름 아래에 다음과 같이 쓰여진 것입니다.

메소드 수신자의 이름은 그 ID를 반영해야합니다. 종종 해당 유형의 하나 또는 두 글자 약어 (예 : "클라이언트"의 경우 "c"또는 "cl")입니다. "me", "this"또는 "self"와 같은 일반적인 이름, 함수와 반대로 메소드에 더 중점을 둔 객체 지향 언어의 일반적인 식별자를 사용하지 마십시오. 그 역할이 명백하고 다큐멘터리 목적을 제공하지 않기 때문에, 이름은 메소드 인수의 이름만큼 설명적일 필요는 없습니다.

필자는 개인적으로 항상 "this"를 식별자로 사용했습니다. "this"는 함수를 작성하고 편집 할 때 수행하는 작업의 초점이기 때문입니다. 그것은 올바르게 들리며 (적어도 나에게는) 의미가 있습니다.

이름이 설명이 필요하지 않은 경우, 그 역할은 명백하며, 다큐멘터리 목적이 아닙니다 . 왜 "this"의 사용이 눈에 띄게됩니까?

우리는 그 스타일 가이드의 저자에게 확실히 알도록 요청해야하지만, 내가 그에게 동의하는 주된 이유 는 다른 언어보다 Go에서 struct와 method 사이의 연결이 훨씬 느슨하기 때문이라고 생각합니다 .

본질적으로 다음과 같은 메소드를 작성할 때 :

func (m *MultiShape) area() float64 {
  ...
}

이것은 다음과 같은 함수를 작성하는 것과 거의 동일합니다.

func area(m *MultiShape) float64 {
  ...
}

유일한 차이점은 함수 / 메서드를 호출하는 방식이 약간 변경되었다는 것입니다.

다른 언어에서 this/ self/ whatever 변수는 일반적으로 언어에 의해 마술처럼 제공되거나 개인 메소드에 대한 특별 액세스 권한과 같은 특수 특성이 있습니다 (Go에는 개인 필드 / 방법이 없음을 기억하십시오). "수신자"는 여전히 어느 정도 "마 법적으로 제공"되고 있지만, 계산되지 않는 일반적인 함수 인수와 매우 유사합니다.

또한 "전통적인"OOP 언어에서 struct / class '메소드는 모두 struct / class 정의와 함께 제공되므로 더 이상 외부에서 추가 할 수 없습니다. Go에서, 내가 아는 한, 누구든지 (물론 자신의 코드 범위 내에서) 더 많은 메소드를 추가 할 수 있습니다.

나는 충분히 작성하지 않았다. 나만의 스타일 가이드를 만들기 위해 가라. 그러나 개인적으로 나는 this그들이받는 구조체와 동일한 파일에 정의 된 메소드와 다른 파일의 구조체에 첨부하는 메소드에 대해 더 설명적인 수신자 이름을 사용할 것이다. .

이 스타일 가이드에 확신이 없으며 this, me또는 보다 나은 것이 없다고 생각 self합니다. 때문에 this, me또는 self그것이 슈퍼 명확한 변수가 컨텍스트 구조체의 인스턴스라고합니다. 소문자 struct name 변수가 나쁜 아이디어라고 말하는 것이 아닙니다. 나는 this그것을 명확하게 하는 방식을 좋아합니다 .

이것은 this실제 키워드를 컴파일러에 의미하는 JavaScript의 관점에서 볼 수 있지만 객체 유형에 대한 두 글자 약어로 괜찮다면 대신 사용하기가 쉬워야합니다. 차이가 발생하는 이유는 점진적으로 더 깊은 비동기 코드가 상당히 큰 블록에서 "this"또는 수신자가 더 깊은 컨텍스트에있는 것을 잘못 해석하는 것이 매우 쉽다는 것입니다. 그리고 그것은 같은 물체가 아닐 수도 있습니다.

예를 들어 JavaScript에서 제어 모듈은 대화 상자를 시작하고 그에 대한 onLoad함수를 인라인으로 선언 할 수 있습니다. 그러나이 시점에서 다른 코더가 대화 상자가 아닌 제어 모듈을 참조하기 위해 this내부 onLoad에서 잘못 해석하는 것이 매우 쉬울 수 있습니다 . 혹은 그 반대로도. 컨트롤이 ctrl대화 상자로 표시되어 있으면이를 피할 수 있습니다 dg.