2. 노개북 [CleanCode 2일차]

TIL (Today I Learned)

2024.01.28

오늘 읽은 범위

• 2. 의미 있는 이름

기억하고 싶은 내용

2. 의미 있는 이름

의도를 분명히 밝혀라

의도가 드러나는 이름을 사용하면 코드 이해와 변경이 쉬워진다

// Bad
int d; // elapsed time (unit: day)

// Good
int elapedTimeInDays;

아래처럼 코드를 작성할 수 있다

public List<int[]> getThem() {
    List<int[]> list1 = new ArrayList<int[]>();
    for (int[] x : theList)
        if (x[0] == 4)
            list1.add(x)
    return list1;
}

위와 같은 코드는 독자가 다음과 같은 정보를 안다고 가정하는 것이다.

1. theList에 무엇이 들어있는가? 게임판
2. theList에서 0번째 값이 왜 중요한가? 칸의 상태
3. 값 4는 무슨 의미인가? 깃발이 꽂힌 상태
4. 함수가 반환하는 리스트 list1을 어떻게 사용하는가? 깃발이 꽂힌 위치 리스트

따라서 위의 코드를 아래처럼 변경하면 좀 더 이해하기 쉬워진다.

public List<int[]> getFlaggedCells() {
    List<int[]> flaagedCells = new ArrayList<int[]>();
    for (int[] cell : gameBoard)
        if (cell[STATUS_VALUE] == FLAGGED)
            flaggedCells.add(cell);
    return flaggedCells;
}

추가로 cell을 class로 만들어서 isFlagged() 함수를 만들어도 좋을 것 같다.

그릇된 정보를 피하라

그릇된 단서는 코드의 의미를 흐린다.

• 널리 쓰이는 의미가 있는 단어

hp, aix, sco는 유닉스 플랫폼이나 변종을 나타내는 의미인데, 직각삼각형의 빗변(hypotenuse)의 약어로 hp를 사용하면 그릇된 정보를 제공할 수도 있다.

• 실제 List가 아닌데 List로 명명

여러 계정이 담고 있는 컨데이너가 List가 아닌데 accountList로 명명하지 말자.
단순히 accounts로 명명해도 좋다.

• 서로 비슷한 이름

한 모듈에서 XYZControllerForEfficientHandlingOfStrings, XYZControllerForEfficientStorageOfSrings를 사용하지 말자.
두 단어의 차이를 알아내는 데 시간이 걸렸다면, 사용하지 말자.

• 일관성이 떨어지는 표기법

유사한 개념은 유사한 표기법을 사용하자

• 소문자 L과 대문자 O는 변수

int var01; // Number 0, Number 1
int var0l; // Number 0, Lowercase L
int varO1; // Uppercase O, Number 1
int varOl; // Uppercase O, Lowercase L

헷갈린다.

의미 있게 구분하라

보통 이 경우 사용하는 방식이 연속된 숫자를 덧붙이거나 불용어를 추가하는 방식이다.
아래 방식을 사용하지 말라는 것은 아니며, 해당 방식이 변수에 의미를 줄 수 있다면 사용해도 된다.
단순히 컴파일 통과를 위해 사용하는 것은 금물이다.

• a1, a2, ... 와 같은 변수는 아무런 정보를 제공하지 못한다.
• Product라는 클래스가 있을때 ProductInfo, ProductData처럼 Info, Data 역시 아무런 정보를 제공하지 못한다.
• 변수이름에 Variable, 표 이름에 Table, name 변수에 String, 클래스 변수에Object를 사용하는 것이 과연 의미가 있을지 생각해보자.

읽는 사람이 차이를 알도록 이름을 지어라.

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

사람들은 단어에 능숙하다.

genymdhms vs generationTimestamp

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

문자 하나를 사용하는 이름과 상수는 검색하기 힘들다.
이런 관점에서는 긴 이름이 짧은 이름보다 좋다.
검색하기 쉬운 이름이 상수보다 좋다.
이름을 의미 있게 지으면 함수가 길어진다.

WORK_DAYS_PER_WEEK vs 5
그렇지 않으면 5가 들어가는 모든 이름을 검색해야 한다.

인코딩을 피하라

• 헝가리식 표기법

예전에는 타입을 따로 명시하지 않았기 때문에 변수 이름을 통해 타입을 유추해야 했지만 지금은 그렇지 않다.

• 멤버 변수 접두어

클래스와 함수는 접두어가 필요없을 정도로 작아져야 한다.
멤버 변수를 다른 색상으로 표시해줄 IDE를 활용하면 된다.

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

이 경우는 어쩔 수 없고 둘 중에 하나를 골라야 한다면, 구현 클래스에 접두어나 접미어를 붙이는 게 낫다.

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

변수 이름을 자신이 아는 이름으로 변환한다면 바람직하지 못하다.
전문가 프로그래머는 명료함이 최고라는 사실을 이해한다.

클래스 이름

클래스 이름과 객체 이름은 명사나 명사구가 적합하다.
좋은 예: Customer, WikiPage, Account 등
나쁜 예: Manager, Processor, Data, Info 등 + 동사

메서드 이름

메서드 이름은 동사나 동사구가 적합하다.
좋은 예:postPayment, deletePage, save 등 + get, set, is

기발한 이름은 피하라

재미난 이름보다 명료한 이름을 선택해라.

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

같은 클래스에

• fetch, retrieve, get
• controller, manager, driver 등

이렇게 섞어서 쓰면 혼란스럽다

말장난을 하지 마라

다른 개념에 같은 단어를 사용한다면 말장난에 불과하다.
숫자를 더하는 것, 리스트에 값을 추가하는 것 모두 add를 사용하면 말장난이다.

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

요구자보다 프로그래머들이 이해할 수 있는 용어를 사용하자.

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

적절한 프로그래머 용어가 없다면 문제 영역에서 가져와 사용하고 분야 전문가에서 의미를 물어 파악할 수 있는 이름으로 사용하면 된다.

의미 있는 맥락을 추가하라

스스로 의미가 분명한 이름이 있지만 대다수는 그렇지 않다.
맥락을 부여하고 안된다면 접두어를 붙여라.

state라는 변수는 주소들 사이에서는 의미가 통하나, 단독으로 있을 경우 주소의 의미로 이해를 못할 수 있다.
이때는 접두어를 붙여 addrState처럼 사용할 수 있다.
아니면 Address라는 클래스를 만들어도 된다.

불필요한 맥락을 없애라

일반적으로 짧은 이름이 긴 이름보다 좋다. 불필요한 맥락은 빼라.
accountAddress나 customerAddress 보다 Address가 더 낫다.

결론

좋은 이름을 선택하기에는 설명 능력이 뛰어나고 문화적 배경도 같아야 한다.
다른 개발자가 반대할까 두려워 이름을 바꾸지 않는 경우가 많다.
그렇다고 코드를 개선하려는 노력을 중단해서는 안된다.

분명히 이름을 개선하면 단기적인 효과는 물론 장기적인 이익도 보장한다.

오늘 읽은 소감

진짜 어떻게 코딩을 하면서 한 번쯤은 내가 후회하고 고민했던 부분이 다 정리가 되어 있는 것 같다.
평소에 그냥 테스트용 코드를 짤 때 a1, a2 이렇게 코드를 짜두고, 다음에 사용하려고 다시 보면 이해가 안되는 경우가 많아서 후회를 많이 했던 경험이 자주 있었다.
단순한 코드를 짜더라도 이렇게 이름부터 고민하는 습관을 들여야겠다는 생각이 들었다.

궁금한 것

없습니다

오늘 읽은 다른사람의 TIL

https://nomadcoders.co/community/thread/9169

이 책을 읽으려는 이유