[Golang] Go의 Naming Convention (네이밍 컨벤션) (Go스러운 코딩 시리즈)

Writing is easy, but reading is painful.

개발자로 살다보면, 코드의 가독성을 높이고 협업하기 좋은 코드를 작성하고자 하는 욕심이 있을 것이다. 특정 프로그래밍 언어를 잘 사용할 수 있다고 하려면 복잡한 문제를 해결해내는 코드 작성뿐 아니라 누군가와 협업을 하고, 서로 이해 가능한 코드를 짤 수 있어야 하는데, 이를 위해서는 규칙과 convention이 필요하다.

 

Go에서는 이를 “Go를 Go답게 쓴다"라고 표현하는데 이와 관련해서 잘 정리된 글들과, Go Effective의 글들을 참고해서 “Go를 Go답게” 쓰는 방법에 대한 시리즈를 다루고자 한다.

 

다른 시리즈로는 Go의 주석(Comment) 컨벤션에 대해 정리한 글이 있는데 참고 바란다. 

 

본 글에서는 go의 Naming convention에 대해서 다룬다.

 

MixedCaps or mixedCaps

Go에서는 첫 문자가 대문자냐 소문자냐에 따라서 해당 이름의 visibility가 결정된다.

쉽게 말하면 대문자로 시작해야만 그 패키지를 import한 곳에서 접근할 수 있는 exported name이 된다.

 

이런 규칙에 따라 Go에서는 MixedCaps(exported), 또는 mixedCaps 표기법을 사용한다.

쉽게 말해서 특정 identifier를 패키지 외부에 노출시키기 위해서는 첫번째 character를 대문자로 사용하고(MixedCaps), 다른 패키지에서 사용하지 못하게 하기 위해서는 mixedCaps을 사용하면 된다. 여러 단어로 된 이름을 명명할 때는 camel case를 따른다고 생각하면 쉽다.

 

예를 들어 보겠다.

package test
type A struct {

}
// Do is an exported method and is accessible in other packages
func (a A) Do() string {
 return a.doMagic("Awesome")
}
// do is only visible inside this package
func (a A) do(input string) string {
 return input
}

위 예시에서 do 메소드는 mixedCap을 사용하고 있기 때문에, 외부 패키지에서 패키지를 import 후에 do를 호출하려고 하면 compile-time error가 발생한다.

 

Package names (패키지 명명 규칙)

Go에서는 package name을 통해서 package의 내용을 import할 수 있다. 따라서 package이름에도 명명 규칙이 있다. 일단 패키지 이름은 lower case, single-word name이어야 한다. underscore나 mixedCaps을 사용하지 않는다.

 

또한 import할 때는 패키지의 디렉토리를 모두 포함시킨다. 예를들어 base64라는 패키지가 encoding 디렉토리 안에 있을 경우에는 "encoding/base64" 로 import하되, base64 로 접근한다. (encodingBase64 이런 것 아님)

 

Getters/Setter names (Getter/Setter 명명 규칙)

Go에서 특정 객체에 대한 getter와 setter를 설정하기 위해서는 특정 규칙을 따라야 한다.

 

예를 들어 특정 객체의 owner(lower case, unexported)라는 필드에 대한 getter method를 구현할 때는 GetOwner보다는 Owner로 네이밍 해야 한다. 하지만 setter에 대해서는 SetOwner로 네이밍 할 수 있다.

owner := obj.Owner()
if owner != user {
    obj.SetOwner(user)
}

 

Interface names (인터페이스 명명 규칙)

기본적으로 하나의 메소드만 가지는 interface의 이름은 MethodName + er = InterfaceName로 정한다.

하지만 만약 여러 개의 메소드를 가진 interface의 경우에는 꼭 위 규칙을 따라야하는건 아니다. 필자는 그냥 주로 특별한 경우가 아니라면 -er suffix를 붙이고 있다.

 

Variable names(변수 명명 규칙)

Go는 기본 적으로 mixedCaps를 사용하고 최대한 짧은 이름을 추천한다. 하지만 때로는 좀 더 descriptive한 이름을 사용해야할 때가 있고, 때로는 single-letter identifier(i e.g.)를 사용할 때가 있다. 필자도 아래 케이스에는 어떻게 이름을 설정하는게 좋을지 궁금했고, 크게 아래와 같이 구분해볼 수 있겠다.

 

single-letter name

local variable에 한해서는 그냥 single-letter를 사용해도 괜찮다. 예를 들어 map을 iterate할 때나, for loop을 iterate할 때 등에서는 굳이 변수명을 idx, key, value이런식으로 작성할 필요없이 single-letter를 사용한다.

for k, v := range {map} 

for i :=0; i < len({slice variable})

Shorthand name

가능하다면 짧게 작성해야 겠지만, 단어 하나만으로 해당 변수를 설명할 수 없다면 mixedCaps 표기법으로 좀 더 descriptive하게 변수명을 정할 수 있다.

pid // Bad (does it refer to podID or personID or productID?)
spec // good (refers to Specification)
addr // good (refers to Address)

Unique name (HTTP, API, etc)

HTTP, API와 같은 acronym의 경우에는 그냥 uppercase를 유지한다.

• userID instead of userId
• productAPI instead of productApi

 

Go 답게 코딩하자! 

참고자료:

https://betterprogramming.pub/naming-conventions-in-go-short-but-descriptive-1fa7c6d2f32a

https://go.dev/doc/effective_go