네이밍 관련 글 정리

다음 글들의 내용을 취합해서 정리한 내용입니다.

# 클래스, 인터페이스

- 명사여야 한다.

: Happy -> Happiness

- 명확한 형용사를 사용하라.

- Manager, Helper 같은 무의미한 단어를 사용하지 말라.

: 만약 사용해야할 필요가 있다면, 이름이 안좋거나 설계가 안좋은 것인데 후자일 가능성이 높다. 클래스나 인터페이스는 자기 자신을 manage하거나 help해야만 한다.

: ConnectionManager -> Connection

: XmlHelper -> XmlDocument, XmlNode, etc.

- 만약 클래스명이 뭔가를 이해하기 쉽게 표현하지 못한다면 구체적인 은유(메타포)를 사용해라.

: IncomingMessageQueue -> Mailbox

: CharacterArray -> String

: SpatialOrganizer -> Map

# 메소드

- 동사를 사용해서 지어라.

- 간결하게 지어라.

: list.GetNumberOfItems() -> list.count()

- 그렇다고 너무 간결하지 짓지는 말아라.

: list.Verify() -> list.ContainsNull()

- 축약어를 쓰지 말아라.

: list.Srt() -> list.Sort()

- 서로 다른 타입을 리턴하는 메소드가 있을 때에만 리턴 타입을 메소드명에 포함시킨다.

: list.GetCountInt() -> list.GetCount()

: message.GetIntValue(), message.GetFloatValue()

- And, Or를 쓰지 말아라.

: 만약 접속사를 쓰게 된다면 메소드가 너무 많은 기능을 하는 것일 수 있으니 기능을 쪼개고 이름도 그에 맞게 지어라.

: mail.VerifyAddressAndSendStatus() -> mail.VerifyAddress(), mail.SendStatus()

: 만약 원자적인 동작을 보장하고 싶은 경우라면, 전체 동작에 대한 이름을 짓거나 전체를 캡슐화하는 클래스를 만드는 것을 고려해봐라.

- 만약 이름 짓는데 애를 먹고 있다면 설계가 잘못된 가능성이 있을 수 있다. 너무 많은 일을 한번에 하거나 뭔가 중요한 것을 놓쳤을지도 모른다. 보통 설계가 잘안되면 이름도 잘 안지어지고 이름이 잘지어지면 설계도 마음에 드는 경우가 많다.

- process, compute는 좋지 않은 선택이다. 대부분의 코드가 뭔가 process하거나 compute한다.

- 메소드에 의미있는 이름을 지어라. 메소드의 정확한 액션을 기술해야하고 대부분 동사로 시작해야 한다.

- 메소드 주석을 다는 습관을 들이면 메소드가 무엇을 하는지 기술하게됨으로써 메소드 이름을 정확하게 짓는데 도움이 된다.

메소드 주석이 좋으면 메소드명은 주석에서 몇 단어를 선택하는 것만으로 잘 지을 수 있다. 만약 주석과 메소드명이 서로 다르다면 둘 중 하나는 잘못된 것이다.

- O(1) 복잡도를 가지는 메소드만 get접두어를 사용해라. 그 외에는 더 구체적인 동사를 사용해라.

e.g 데이터베이스에서 데이터를 가져오는 메소드 : getData() -> fetchData()

- do를 사용하지 말아라. 모든 메소드가 뭔가 한다. do는 어떤 추가 정보도 제공하지 못한다.

call, execute, run, prepare도 비슷한 유형이니 사용하는게 항상 안좋은건 아니지만 다른 단어가 없는지 한번쯤 더 생각해보자.

- boolean을 리턴하는 메소드는 is, are, was, were, can, could, may, might, must, shall, should, will, would 같은 단어로 시작하게 하자.

- 만약 메소드가 속한 객체를 통해 행위의 목적어를 알 수 있다면 메소드명에서 동사만 사용해도 충분하다.

e.g message.saveMessage() -> message.save()

- 메소드명에 파라미터를 기술하지 말아라. 메소드 시그니쳐는 메소드명과 파라미터를 포함하는 개념이다. 파라미터를 메소드명에 기술하는 것은 중복이다.

e.g findUserByUserIdAndToken(userId, token) -> findUser(userId, token)

- 메소드 이름을 handleClick과 같이 짓지 말아라.

: 메소드가 어떻게 사용되는지 적은 메소드명이 가장 게으른 메소드명이다. 메소드명은 무엇을 하는지 나타내야 한다.

: 메소드 재사용이 불가능하다.

- 하지만 외부 인터페이스 후크 메소드에서만큼은 어떻게 호출되는지를 표현하는게 권장된다. 그게 더 명료한 최선의 선택이다.

: onClick() 같은 메소드

- initAndDisplaySettingMenu()와 같은 행위 나열보다는 한단계 더 추상적인 레벨에서 표현하는게 좋다.

: 행위가 늘어날 때마다 AndXXX를 붙일 것인가?

# 변수명

- 변수의 scope에 따라 충분히 짧거나 긴 변수명을 사용해라.

: 루프 카운터 변수 : 1자

: 조건문, 반복문 변수 : 1단어

: 메소드 : 1~2단어

: 클래스명 : 2~3단어

: 글로벌 변수 : 3~4단어

- 한 메소드나 조건문에서 같은 변수를 다른 목적으로 재사용하지 말고 다른 이름을 가지는 새로운 변수를 만들어라.

- 50자 이상되는 긴이름을 짓지 말아라. 읽기 힘들다.

- 변수 타입을 변수명에 넣지 말아라.

: IDE로 변수 타입을 확인하는게 어려운 일이 아니다. 이름에 타입을 넣는 것은 불필요하다.

* hostInputStream -> rawHostData

* hostString -> hostText, hostJson, hostKey

* intPort -> portNumber

: 컬렉션 타입 변수는 복수형을 사용하고 타입 대신 그 변수가 무엇인지를 표현해라.

* hostList -> hosts

- 되도록 구체적인 표현을 사용해라

: unhealthyHostFinder -> overloadedCPUFinder

- 간단한 주석은 변수명에 포함시켜라

: name // First and last name -> fullName

- 진부한 단어를 피하라

: val, value, result, retval, tmp, str ...

- 진부하더라도 널리 사용되는 관용적인 표현은 괜찮다.

: 반복문의 i, j

: limit, quantity를 위한 n

: catch 구문의 e

- 다음과 같은 경우에는 한두자 정도의 변수명을 써도 괜찮다.

: 선언과 사용이 5라인 이내인 경우

: 타입 이외에 더 나은 이름이 없는 경우

: 코드 읽는 사람이 코드 그 부분에서 너무 많은 것들을 기억하고 있지 않은 경우

- 무분별한 일회성 변수를 사용하지 말라

: 일회성 변수가 유용할 때도 있지만 그렇지 않다면 안쓰는게 낫다.

- 일회성 변수가 유용할 때는 다음과 같다.

: 한 라인이 너무 길어질 때

: 복잡한 표현식을 쪼갤 때

: 이해하기 힘든 코드에 대한 설명으로 변수명을 사용할 때

# 클래스, 인터페이스

# 메소드

# 변수명

티스토리툴바