golint
약간 고민을 했던 주제였다. Jenkins에 golint를 이용한 체크 로직이 들어있기 때문에 이 규칙에 준수를 해줘야 하는데, 통과시키려고 코드를 정리하던 중 제목과 같은 에러메세지가 발생했다. 에러를 요약하자면 사용하기엔 짜증나는 타입을 만들어놨다는 것이었다. 어떤 코드가 그렇게 짜증이 났을까?
type foo struct{}
func Bar() foo {
return foo{}
}
다음과 같이 코드를 사용하면 외부에서는 이런 식으로 값을 받아오게 된다.
func anyFunc() {
result := Bar()
}
private struct type인 foo 형식을 외부에서 받아오게 되는 모양새를 취하게 되는데, 만약 이 값을 험하게 다뤄, 반환에 반환을 하고 다시 전달전달... 이런 방식으로 사용을 하게 된다면, 직접 선언할 순 없지만(깡통 타입을 정의할 수 없지만) 어딘가에서 분명 생성되어서 실제로 다뤄지고 있는, 사용하기에 귀찮아질 수 있는 타입이 되는 것이다. 이러한 정책을 Jenkins에 걸어놓으면 위와 같은 코드는 build fail로 이어진다. 비극적인 일이다. 근데, 생각을 해보면, 과연 사용하기 annoying 하다는 이유로 fail을 발생시키는 것이 옳은일 일까? 라는 생각이 든다.
만약, `type foo`가 `Bar()` 선언 없이 절대로 독립적으로 존재할 수 없는 타입이라면? Public으로 선언하고 깡통 타입을 만들 수 있게 한들 실제로 사용할 수 있는 여지가 존재하지 않는다면, 그러면 그냥 위처럼 조금 귀찮은 코드가 완성되더라도 잘 다뤄서 쓰는게 오히려 낫지 않을까?
라는 생각을 조금 해봤는데, 거꾸로 말해서 Public으로 만들고 안 쓰면 되는거니까 언제든 활용의 여지를 남겨두는 것도 나쁘지 않겠다는 생각이 들었다. golint가 51퍼센트 정도 맞는 느낌? 그냥 그런 느낌이다.
아, 해결방법은 간단하다.
foo를 Public으로 만들어주면 끝이다.
type Foo struct{}
func Bar() Foo {
return Foo{}
}
'기술 > Go' 카테고리의 다른 글
[Go] Beego를 이용한 서버 구축 조금만 찍먹해보기 (0) | 2022.05.30 |
---|
댓글