IT Book/클린 코드(Clean Code)

[Clean Code] 2. 의미 있는 이름 - 클린 코드 정독하기

잇트루 2023. 3. 18. 23:26
반응형

의미 있는 이름

소프트웨어에서 이름은 어디에나 쓰인다. 변수, 함수, 인수, 클래스, 패키지 등에도 이름을 붙인다. 뿐만 아니라 소스 파일, 소스 파일이 담긴 디렉터리, jar, war 파일에도 이름을 붙인다.

따라서 이름을 잘 지어야 많은 것들이 편해진다.

 

클린 코드에서는 이름을 잘 짓기 위한 몇 가지 간단한 규칙을 소개한다.

 

 

의도를 분명히 하라

의도가 분명한 이름은 정말로 중요하다. 좋은 이름을 지으려면 시간이 걸리지만, 좋은 이름으로 인해 절약하는 시간이 훨씬 더 많다.

 

변수나 함수, 클래스의 이름에는 존재 이유, 수행 기능, 사용 방법 등에 대한 질문에 답해야 한다. 따로 주석이 필요하다면 의도를 분명히 표현하지 못했다는 것이다.

 

변수

나쁜 예

int d; // 경과 시간(단위: 날짜)
  • bad case의 변수 d는 아무 의미도 드러나지 않는다. 날짜라는 느낌도 안 든다.
  • 측정하려는 값과 단위를 표현하는 이름이 필요하다.

 

좋은 예

int elapsedTimeInDays;
int daySinceCreation;
int daySinceModification;
int fileAgeInDays;
  • good case와 같이 의도가 드러나는 이름을 사용하면 코드 이해와 변경이 쉬워진다.

 

함수(메서드)

나쁜 예

public List<int[]> getThem(){
    List<int[]> list1 = new ArrayList<int[]>();
    
    for (int[] x : theList)
        if (x[0] == 4)
            list1.add(x);
            
    return list1;
}
  • 위 코드에는 복잡한 문장은 없으나 코드가 하는 일을 짐작하기 어렵다.
  • 공백과 들여 쓰기도 적당하며, 변수 3개와 상수 2개뿐이다.
  • 하지만, 문제는 코드의 단순성이 아닌 함축성이다.
  • 즉, 코드 맥락이 코드 자체에 명시적으로 드러나지 않는다.

 

좋은 예

public List<Cell> getFlaggedCells(){
    List<Cell> flaggedCells = new ArrayList<Cell>();
    
    for (Cell cell : gameBoard)
        if (cell[STATUS_VALUE] == FLAGGED) // if (isFlagged())
            flaggedCells.add(cell);
            
    return flaggedCells;
}
  • 위 코드와 같이 이름만 붙여도 코드가 상당히 나아진다.
  • 연산자 수와 상수 수는 앞의 예시와 같으며, 들여 쓰기 단계도 동일하다.
  • 그럼에도 불구하고 코드는 더욱 명확해졌다.
  • 더 나아가 int 배열을 사용하는 대신 칸을 간단한 클래스로 만들어 isFlagged()라는 명시적인 함수를 사용하면 더욱 개선할 수 있다.

 

 

그릇된 정보를 피하라

개발자는 코드에 그릇된 단서를 남겨서는 안된다. 그릇된 단서는 코드의 의미를 흐리기 때문이다.

  1. 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해서는 안된다.
    • 예를 들어, hp는 변수 이름으로 적합하지 않다. 빗변(hypotenuse)을 구할 때 훌륭한 약어로 보일지라도, 유닉스 플랫폼이나 유닉스 변종을 가리키는 이름이기 때문에 사용해서는 안된다.
  2. 여러 계정을 그룹으로 묶을 때 실제 List가 아니라면 accountList라 명명하지 않는다.
    • 개발자에게 List라는 단어는 특수한 의미로, 계정을 담는 컨테이너가 List가 아니라면 그릇된 정보를 제공하는 셈이다. List가 아닌 경우 accountGroup, accounts 등으로 명명한다.
  3. 서로 흡사한 이름을 사용하지 않도록 주의한다.
    • XYZControllerForEfficientHandlingOfStrings
    • XYZControllerForEfficientStorageOfStrings
    • 한 모듈에서 위에 있는 두 이름을 사용한다고 가정할 때, 이 둘의 차이를 알아채기 어렵다.
  4. 유사한 개념은 유사한 표기법을 사용한다.
    • 일관성이 떨어지는 표기법은 그릇된 정보다.
  5. 이름으로 그릇된 정보를 제공하는 끔찍한 예는 소문자 L이나 대문자 O 변수다.
int a = 1;

if ( O == 1 )
    a = O1;
else
    l = 01;

 

 

의미 있게 구분하라

컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하는 개발자는 스스로 문제를 일으킨다.

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

 

연속된 숫자를 덧붙이는 경우

public static void copyChars(char a1[], char a2[]){
    for(int i = 0; i < a1.length; i++) {
        a2[i] = a1[i];
    }
}

위 코드의 경우 함수의 인수 이름으로 source와 destination을 사용한다면 코드 읽기가 훨씬 더 쉬워진다.

 

불용어를 추가하는 경우

class Product {

}

class ProductInfo {

}

class ProductData {

}

위와 같이 Product라는 클래스가 있을 때, 다른 클래스를 ProductInfo 혹은 ProductData라 부른다면 개념을 구분하지 않은 채 이름만 달리한 경우이다. Info나 Data는 의미가 불분명한 불용어이다.

 

 

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

사람들은 단어에 능숙하며, 우리 두뇌에서 상당 부분은 단어라는 개념만 전적으로 처리한다. 또한, 단어는 발음이 가능하다. 말을 처리하려고 발달한 두뇌를 활용하지 않는다면 안타까운 손해다.

그러므로 발음하기 쉬운 이름을 선택한다.

 

나쁜 예

class DtaRcrd102 {
    private Date genymdhms;
    private Date modymdhms;
    private final String pszqint = "102";
    /* ... */
};

 

좋은 예

class Customer {
    private Date generationTimestamp;
    private Date modificationTimestamp;
    private final String recordId = "102";
    /* ... */
};

 

 

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

문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다는 문제점이 있다.

  • 7과 MAX_CLASSES_PER_STUDENT가 있다고 가정하면
    • MAX_CLASSES_PER_STUDENT는 검색하여 찾기 쉽다.
    • 7은 7이 들어가는 파일 이름이나 수식이 모두 검색되기 때문에 찾기 까다롭다.

 

이름 길이는 범위의 크기에 비례해야 한다. 변수나 상수를 코드 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다.

for (int j=0; j<34; j++) {
    s += (t[j]*4)/5;
}
int realDaysPerIdealDay = 4;
const int WORK_DAYS_PER_WEEK = 5;
int sum = 0;
for (int j=0; j < NUMBER_OF_TASKS; j++) {
    int realTaskDays = taskEstimate[j] * realDaysPerIdealDay;
    int realTaskWeeks = realTaskDays / WORK_DAYS_PER_WEEK;
    sum += realTaskWeeks;
}

 

 

인코딩을 피하라

문제 해결에 집중하는 개발자에게 인코딩은 불필요한 정신적 부담이다. 인코딩한 이름은 발음하기 어려우며 오타가 생기기도 쉽다.

 

헝가리식 표기법

요즘 나오는 프로그래밍 언어는 훨씬 많은 타입을 지원하며 컴파일러가 타입을 기억하고 강제한다. 게다가 클래스와 함수는 점차 작아지는 추세다. 즉, 변수를 선언한 위치와 사용하는 위치가 멀지 않다.

자바 개발자는 변수 이름에 타입을 인코딩할 필요가 없다. 객체는 강한 타입이며, IDE는 코드를 컴파일하지 않고도 타입 오류를 감지할 정도로 발전했다.

 

따라서, 헝가리식 표기법이나 기타 인코딩 방식은 오히려 방해가 될 뿐이다.

PhoneNumber phoneString; // 타입이 바뀌어도 이름은 바뀌지 않음

 

멤버 변수 접두어

멤버 변수에 m_이라는 접두어를 붙일 필요도 없다. 클래스와 함수는 접두어가 필요 없을 정도로 작아야 마땅하다.

또한, 멤버 변수를 다른 색상으로 표시하거나 눈에 띄게 부여주는 IDE를 사용하는 것이 마땅하다.

 

나쁜 예

public class Part {
    private String m_dec; // 설명 문자열
    void setName(PString name) {
    	m_dsc = name;
    }
}

 

좋은 예

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

 

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

인터페이스 클래스와 구현 클래스와 같은 경우 인코딩이 필요하다.

  • 인터페이스 클래스와 구현 클래스 중 구현 클래스의 이름을 인코딩하는 것이 좋다.

 

예를 들어, 도형을 생성하는 Abstract Factory가 있다고 가정하면,

public class ShapeFactory implements IShapeFactory {

}

위 코드보다 아래의 코드가 더 좋다.

public class ShapeFactoryImpl implements ShapeFactory {

}

 

 

 

자신의 기억력을 자랑하지 마라

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

 

문자 하나만 사용하는 변수 이름은 문제가 있다. 하지만 루프에서 반복 횟수를 세는 변수 i, j, k는 괜찮다. 단, 루프 범위가 작고 다른 이름과 충돌하지 않을 경우에만 괜찮다.

 

명료함이 최고 - 전문가 개발자는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.

 

 

클래스 이름

클래스 이름과 객체 이름은 명사나 명사구가 적합하다.

  • Customer, WikiPage, Account, AddressParser 등이 좋은 예다.
  • Manager, Processor, Data, Info 등과 같은 단어는 피하고, 동사는 사용하지 않는다.

 

 

메서드 이름

메서드 이름은 동사나 동사구가 적합하다.

  • postPayment, deletePage, save 등이 좋은 예다.
  • 접근자(Accessor), 변경자(Mutator), 조건자(Predicate)는 javabean 표준에 따라 값 앞에 get, set, is를 붙인다.

 

 

기발한 이름은 피하라

HolyHandGrenade라는 함수는 기발한 이름이지만 DeleteItems가 더 좋다.

즉, 재미난 이름보다 명료한 이름을 선택하는 것이 좋다.

  • 특정 문화에서만 사용하는 농담은 피하는 편이 좋다.
  • 의도를 분명하고 솔직하게 표현한다.

 

 

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

  • 추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다.
    • fetch, retrieve, get으로 제각각 부르면 혼란스럽다. 어느 클래스에서 어느 이름을 썼는지 기억하기 어렵다.
    • 마찬가지로, 동일 코드 기반에 controller, manager, driver를 섞어 쓰면 혼란스럽다.
  • 일관성 있는 어휘는 코드를 사용한다.

 

 

말장난을 하지 마라

한 단어를 두 가지 목적으로 사용하면 안된다. 다른 개념에 같은 단어를 사용한다면 그것은 말장난에 불과하다.

  • 예를 들어, 같은 맥락이 아닌데도 일관성을 고려해 add라는 단어를 선택할 때가 있다.
    • add 메서드 모두가 기존 값 두 개를 더하거나 이어서 새로운 값을 만든다고 가정한다.
    • 새로 작성할 메서드는 집합에 값 하나를 추가한다면 이는 add 메서드와는 맥락이 다르다.
    • insert나 append라는 이름이 적당하다.
    • 만약, 새로 작성할 메서드를 add라고 부른다면 이는 말장난이다.

 

 

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

코드를 읽을 사람도 개발자라는 사실을 명심한다.

  • 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등은 사용해도 괜찮다.
  • 모든 이름을 문제 영역(domain)에서 가져오는 정책은 현명하지 못하다.
  • 기술 개념에는 기술 이름이 가장 적합한 선택이다.

 

 

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

적절한 개발자 용어가 없다면 문제 영역에서 이름을 가져온다.

  • 우수한 개발자와 설계자라면 해법 영역과 문제 영역을 구분할 줄 알아야 한다.
  • 문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다.

 

 

의미 있는 맥락을 추가하라

스스로 의미가 분명한 이름이 없지 않다. 하지만 대다수 이름은 그렇지 못하다.

  • 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다.
  • 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다.

firstName, lastName, street, houseNumber, city, state, zipcode라는 변수가 있다면, 주소라는 사실을 금방 알아챌 수 있다. 하지만, 어느 메서드가 state라는 변수 하나만 사용한다면, 변수 state가 주소의 일부라는 것을 알아챌 수 없을 것이다.

 

맥락이 불분명한 변수

private void printGuessStatistics(char candidate, int count) {
    String number;
    String verb;
    String pluralModifier;
    
    if (count == 0) {
        number = "no";
        verb = "are";
        pluralModifier = "s";
    } else if (count == 1) {
        number = "1";
        verb = "is";
        pluralModifier = "";
    } else {
        number = Integer.toString(count);
        verb = "are";
        pluralModifier = "s";
    }
    
    String guessMessage = String.format("There %s %s %s%s", verb, number, candidate, pluralModifier);
    print(guessMessage);
}

 

맥락이 분명한 변수

public class GuessStatisticsMessage {
    private String number;
    private String verb;
    private String pluralModifier;
 
    public String make(char candidate, int count) {
        createPluralDependentMessageParts(count);
        return String.format("There %s %s %s%s", verb, number, candidate, pluralModifier);
    }
 
    private void createPluralDependentMessageParts(int count) {
        if (count == 0) {
            thereAreNoLetters();
        } else if (count == 1) {
            thereIsOneLetter();
        } else {
            thereAreManyLetters(count);
        }
    }
 
    private void thereAreManyLetters(int count) {
        number = Integer.toString(count);
        verb = "are";
        pluralModifier = "s";
    }
 
    private void thereIsOneLetter(){
        number = "1";
        verb = "is";
        pluralModifier = "";
    }
 
    private void thereAreNoLetter(){
        number = "no";
        verb = "are";
        pluralModifier = "s";
    }
}

 

 

불필요한 맥락을 없애라

일반적으로 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다. 이름에 불필요한 맥락을 추가하지 않도록 주의한다.

  • accountAddress와 customerAddress는 Address 클래스 인스턴스로는 좋은 이름이나 클래스 이름으로는 적합하지 못하다. Address는 클래스 이름으로 적합하다.
  • 포트 주소, MAC 주소, 웹 주소를 구분해야 한다면 PostalAddress, MAC, URI라는 이름으로 의미를 분명하게 하는 것도 괜찮다.

 

https://link.coupang.com/a/ScUC0

 

Clean Code(클린 코드):애자일 소프트웨어 장인 정신

COUPANG

www.coupang.com

이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.

반응형
저작자표시

'IT Book > 클린 코드(Clean Code)' 카테고리의 다른 글

[Clean Code] 6. 객체와 자료구조 - 클린 코드 정독하기  (0) 2023.07.20
[Clean Code] 5. 형식 맞추기 - 클린 코드 정독하기  (0) 2023.06.08
[Clean Code] 4. 주석 - 클린 코드 정독하기  (1) 2023.05.12
[Clean Code] 3. 함수 - 클린 코드 정독하기  (1) 2023.04.24
[Clean Code] 1. 깨끗한 코드 - 클린 코드 정독하기  (0) 2023.03.17

'IT Book/클린 코드(Clean Code)'의 다른글

  • 현재글[Clean Code] 2. 의미 있는 이름 - 클린 코드 정독하기

관련글

댓글

티스토리툴바