[Go] 끔찍한 Receiver Name Rule

그냥 내 불평불만을 써놓은 글이다.

일단 고퍼들은 이상할 정도로 대충 지은 이름에 관대하다.

언어를 초월해서 변수명은 축약 없이 명확하게 짓자는게 합의가 된 상황에도 불구하고, 대충 축약한 변수명을 남발하는 문화가 만연하다. context를 ctx로 줄이는건 예사고, SomethingFunctionFactory 같은 긴 타입의 변수도 그냥 sff 같은 식으로 대충 치고 지나가는 경우가 매우 많다.

그건 그렇다고 치자. 근데 리시버 네임 룰에 대해서도 이상한 자기들만의 규칙을 갖고 있다.
Go에서는 아래와 같은 형태로 메서드를 정의하는데

func (st SomeType) DoSomething() {
    // ...
}

사실 저 (st SomeType)는 다른 언어에서의 this 바인딩과 크게 다를 것이 없다.
파이썬의 self, 러스트의 self와도 사실상 동등한 기능이다.

그럼에도 불구하고 Go 표준 컨벤션 가이드에서는 그냥 변수처럼 정의하라고만 강요한다. 린터에서도 팬다.
https://github.com/golang/go/wiki/CodeReviewComments#receiver-names
이에 대해서 별다른 실용적인 근거는 없다. 그럴듯하게 써놨지만 실속은 없다.
그냥 하지 말라는 것이다.

온갖 축약으로 가득한 식별자 지옥으로 가득찬 이 코드가 괜찮아 보이나?

func (sir ShopImageResource) ProcessImage(mr MachineRange) float64 {
	switch sir.Vls{
	case mr.Some:
		return 1
	case mr.To:
		return float64(2) / float64(3)
	case mr.Tree:
		return float64(3) / float64(4)
	case mr.Apple:
		return float64(4) / float64(5)
	case mr.FooBar:
		return float64(self.Width) / float64(self.Height)
	default:
		return 1
	}
}

아니면 그냥 self나 this로 컨텍스트를 정의한 것이 나아보이나?

func (self ShopImageRatioOption) ProcessImage(mr MachineRange) float64 {
	switch sir.Vls{
	case mr.Some:
		return 1
	case mr.To:
		return float64(2) / float64(3)
	case mr.Tree:
		return float64(3) / float64(4)
	case mr.Apple:
		return float64(4) / float64(5)
	case mr.FooBar:
		return float64(self.Width) / float64(self.Height)
	default:
		return 1
	}
}

리시버는 사실상 해당 함수 영역에서는 고유한 기능을 하기 때문에, 온갖 변수를 뒤섞기보단 고유한 식별자를 하나 정해서 사용하는 것이 보기 좋다.

그래서 나는 this나 self 같은 고유한 키워드로 정의를 하는 편이 더 직관적이고 생산성과 가독성이 뛰어나다고 주장하겠다.
대관절 저따위로 코드를 짤 이유가 어디에 있단 말인가?

Go 커뮤니티는 항상 자기들이 실용적이라고 주장하지만, 사실은 자기들만의 아집에 갇혀있는 부분이 상당히 많다고 느낀다.

스택오버플로에 들어가면 이에 대한 논쟁이 좀 있다.
https://stackoverflow.com/questions/23482068/in-go-is-naming-the-receiver-variable-self-misleading-or-good-practice

참조
https://stackoverflow.com/questions/23482068/in-go-is-naming-the-receiver-variable-self-misleading-or-good-practice