의미 있는 이름

의도를 분명히 밝혀라

의도가 드러나는 이름을 사용하면 코드 이해와 변경이 쉬워진다. 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.

그릇된 정보를 피하라

코드에 그릇된 단서를 남겨서는 안 된다. 그릇된 단서는 코드 의미를 흐린다. 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안 된다.

  • hypotenuse를 약어로 hp라 지칭하면 이 변수는 그릇된 정보를 제공하게 된다. hp는 유닉스 플랫폼이나 유닉스 변종을 가리키는 이름이기 때문이다.
  • 컨테이너가 실제 List가 아닌데 List라는 단어를 사용하면 프로그래머에게 그릇된 정보를 제공하게 된다.
  • 유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다. 일관성이 떨어지는 표기법은 그릇된 정보다.

의미 있게 구분하라

컴파일러를 통과할지라도 연속된 숫자를 덧붙이거나 불용어를 추가하는 방식은 적절하지 못하다. 이름이 달라야 한다면 의미도 달라져야 한다.

연속된 숫자 이름

public static void copyChars(char a1[], char a2[]) {
    ...
}

연속적인 숫자를 덧붙인 이름은 의도적인 이름과 정반대다. 이런 이름은 그릇된 정보를 제공하는 이름은 아니다. 아무런 정보를 제공하지 못하는 이름일 뿐이다.

불용어를 추가한 이름

불용어를 추가한 이름은 아무런 정보도 제공하지 못한다. 예를들어 Product 클래스가 있다. 다른 클래스를 ProductInfo, ProductData라 부른다면 개념을 구분하지 않은 채 이름만 달리한 경우다.
getActiveAccount(), getActiveAccounts(), getActiveAccountInfo() 메서드가 있다. 프로그래머는 어느 함수를 호출해야 할지 알 수 없다. 읽는 사람이 차이를 알도록 이름을 짓자.

발음하기 쉬운 이름을 사용하라

사람들은 단어에 능숙하다. 우리 두뇌에서 상당 부분은 단어라는 개념만 전적으로 처리한다. 그리고 정의상으로 단어는 발음이 가능하다. 말을 처리하려고 발달한 두뇌를 활용하지 않는다면 손해다. 그러므로 발음하기 쉬운 이름을 선택한다. 발음하기 어려운 이름은 토론하기도 어렵다.

검색하기 쉬운 이름을 사용하라

문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다는 문제점이 있다. MAX_CLASSES_PER_STUDENT는 검색하기 쉽지만, 숫자 7은 까다롭다. 7이 들어가는 파일 이름이나 수식이 모두 검색되기 때문이다. 검색하기 쉬운 이름이 상수보다 좋다.
간단한 메서드에서 로컬 변수는 한 문자를 사용해도 된다. 이름 길이는 범위 크기에 비례해야 한다. 변수나 상수를 코드 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다.

인코딩을 피하라

굳이 부담을 더하지 않아도 이름에 인코딩할 정보는 아주 많다. 유형이나 범위 정보까지 인코딩에 넣으면 그만큼 이름을 해독하기 어려워진다. 문제 해결에 집중하는 개발자에게 인코딩은 불필요하다. 인코딩한 이름은 거의 발음하기 어려우며 오타가 생기기도 쉽다.

헝가리안 표기법

컴퓨터 프로그래밍에서 변수 및 함수의 이름 앞에 데이터 타입을 명시하는 코딩 규칙.
요즘 나오는 프로그래밍 언어는 훨씬 많은 타입을 지원한다. 또한 컴파일러가 타입을 기억하고 강제한다. 게다가 클래스와 함수는 점차 작아지는 추세다. 즉, 변수를 선언한 위치와 사용하는 위치가 멀지 않다.
자바 프로그래머는 변수 이름에 타입을 인코딩할 필요가 없다. 객체는 강한 타입이며, IDE는 코드를 컴파일하지 않고도 타입 오류를 감지할 정도로 발전했다. 따라서 이제는 헝가리식 표기법이나 기타 인코딩 방식이 오히려 방해가 된다. 변수, 함수, 클래스 이름이나 타입을 바꾸기가 어려워지며, 읽기도 어려워진다.

PhoneNumber phoneString; // 타입이 바뀌어도 이름은 바뀌지 않는다.

멤버 변수 접두어

멤버 변수에 접두어를 붙일 필요는 없다. 클래스와 함수는 접두어가 필요없을 정도로 작아야 한다. 또한 멤버 변수를 다른 색상으로 표시하거나 눈에 띄게 보여주는 IDE를 사용해야 마땅하다. 게다가 사람들은 접두어를 무시하고 이름을 해독하는 방식을 빨리 익힌다. 코드를 읽을수록 접두어는 관심 밖으로 밀려난다.

public class Part {
    private String m_dsc;
    void setName(String name) {
        m_dsc = name;
    }
}


public class Part {
    String description;
    void setDescription(String description) {
        this.description = description;
    }
}

인터페이스 클래스와 구현 클래스

때로는 인코딩이 필요한 경우도 있다. 예를 들어, 도형을 생성하는 AbstractFactory를 구현하다고 가정하자. 이 팩토리는 인터페이스 클래스다. 구현은 구체 클래스에서 한다. 그렇다면 두 클래스 이름을 어떻게 지어야 할까? 인터페이스 이름은 접두어를 붙이지 않는 편이 좋다. 인터페이스 클래스 이름과 구현 클래스 이름 중 하나를 인코딩 해야 한다면 구현 클래스 이름을 택하자. 그렇다면 클래스 이름은 ShapeFactoryImpl나 CShapeFactory로 지을 수 있다.

변수 이름은 의미를 알아볼 수 있게 짓자

독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다. 이는 일반적으로 문제 영역이나 해법 영역에서 사용하지 않는 이름을 선택했기 때문에 생기는 문제다. 문자 하나만 사용하는 변수는 루프에서 반복 횟수를 세는 경우가 아니면 사용하면 안된다.

클래스 이름

클래스 이름과 객체 이름은 명사나 명사구가 적합하다. Customer, WikiPage, Account 등이 좋은 예다. Manager, Processor, Data, Info 등과 같은 단어는 피하고, 동사는 사용하지 않는다.

메서드 이름

메서드 이름은 동사나 동사구가 적합하다. postPayment, deletePage, save 등이 좋은 예다. 접근자, 변경자, 조건자는 javabean 표준에 따라 값 앞에 get, set is를 붙인다.

생성자를 중복정의할 때는 정적 팩터리 메서드를 사용한다. 메서드는 인수를 설명하는 이름을 사용한다.

Complex fulcrumPoint = new Complex(23.0);   // 생성자

Complex fulcrumPoint = Complex.FromRealNumber(23.0);    // 정적 팩터리 메서드

한 개념에 한 단어를 사용하라

추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다. 예를 들어, 똑같은 메서드를 클래스마다 fetch, retrieve, get으로 제각각 부르면 혼란스럽다. 어느 클래스에서 어느 이름을 썼는지 기억하기 어렵다. 안타깝게도 현실에서는 이름을 기억하기 위해, 라이브러리를 작성한 회사나 그룹이나 개인을 기억해야 하는 경우가 많다. 안 그러면 헤더와 과거 코드 예제를 살피느라 시간을 소모하게 된다.

메서드 이름은 독자적이고 일관적이어야 한다. 그래야 주석을 뒤져보지 않고도 프로그래머가 올바른 메서드를 선택한다.
마찬가지로, 동일 코드 기반에 controller, manager, driver를 섞어 쓰면 혼란스럽다. 예를 들어, DeviceManager와 ProtocolController 가 있다고 가정하자. 이름이 다르면 독자는 당연히 클래스도 다르고 타입도 다르리라 생각한다.

한 단어를 두 가지 목적으로 사용하지 마라

때로는 같은 맥락이 아닌데도 일관성을 고려해 기존 메서드명과 같은 단어를 선택할 수 있다.
예를 들어, 지금까지 구현한 add 메서드는 기존 값 두개를 더하거나 새로운 값을 만든다고 가정하자. 새로 작성하는 메서드는 집합에 값 하나를 추가한다. add라는 메서드가 많으므로 일관성을 지키려면 add라 불러야 하지 않을까? 하지만 새 메서드는 기존 add 메서드와 맥락이 다르다. 그러므로 insert나 append라는 이름이 적당하다.

해법 영역에서 가져온 이름을 사용하라

코드를 읽을 사람도 프로그래머라는 사실을 명심하자. 그러므로 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다. 모든 이름을 문제 영역에서 가져오는 정책은 현명하지 못하다. 같은 개념을 다른 이름으로 이해하던 동료들이 매번 고객에게 의미를 물어야하기 때문이다.

문제 영역에서 가져온 이름을 사용하라

적절한 프로그래머 용어가 없다면 문제 영역에서 이름을 가져오자. 그러면 코드를 유지보수하는 프로그래머가 분야 전문가에게 의미를 물어 파악할 수 있다.
해법 영역과 문제 영역은 구분해야 한다. 문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다.

의미 있는 맥락을 추가하라

스스로 의미가 분명한 이름이 없지 않다. 하지만 대다수 이름은 그렇지 못하다. 그래서 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다. 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다. 예를 들어, firstName, lastName, street, houseNumber, city, state, zipcode라는 변수가 있다. 변수를 훑어보면 주소라는 사실을 금방 알아챈다. 하지만 어느 메서드가 state라는 변수 하나만 사용한다면 state가 주소 일부라는 사실을 알기 힘들다. addrState로 접두어를 추가한다면 맥락이 좀 더 분명해진다. 물론 Address라는 클래스를 생성하면 더 좋다. 그러면 변수가 좀 더 큰 개념에 속한다는 사실이 컴파일러에게도 분명해진다.

불필요한 맥락을 없애라

일반적으로 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다. 이름에 불필요한 맥락을 추가하지 않도록 주의하자. 예를 들어, GSD(Gas Station Deluxe) 모듈에 MailingAddress 클래스를 추가하면서 GSDAccountAddress로 이름을 바꿨다고 가정하자. 나중에 다른 고객 관리 프로그램에서 고객 주소가 필요하다. 이 때 GSDAccountAddress 클래스의 이름은 부적절하다. 이름 17자 중 10자는 중복이거나 부적절하다. 게다가 모든 클래스 이름을 GSD로 시작하겠다는 생각은 바람직하지 못하다. IDE에서 GSD를 입력하고 자동 완성 키를 누르면 IDE는 모든 클래스를 열거한다.

Categories:

Updated:

Comments