Published 2022. 2. 20. 15:00

클린코드 - 1.깨끗한 코드 & 2.의미있는 이름

개발 서적/클린코드

728x90

0. 깨끗한 코드

"나중은 결코 오지 않는다."
- 르블랑의 법칙

나중에 돌아와서 다시 정리하겠다는 생각은 하지말자

나쁜 코드가 쌓일수록 생산성은 떨어지고 청소할 방법이 없어진다

그렇다면 깨끗한 코드란 무엇일까?

공통적으로 얘기하는 깨끗한 코드의 특징은

중복을 피하고, 한 기능만 수행, 제대로 표현, 작게 추상화

즉, 읽기 쉽고 유지보수성이 좋은 코드이다

1. 의도를 분명히 밝혀라

책에서는 의도가 분명한 이름은 정말로 중요하다는 사실을 거듭 강조한다

좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다

변수, 함수, 클래스 등의 이름만으로 존재 이유, 수행 기능, 사용 방법을 유추할 수 있도록 신경 써서 지어야 한다

따라서 주석이 필요하다면 의도를 분명히 드러내지 못했다는 뜻!

예를 들어 보자

int d;	// 경과 시간(단위 날짜)

(나도 실제 코드에서 많이 사용하고 보는 변수명이라 더 와닿았다..)

이름 d는 아무 의미도 드러나지 않는다

아래 코드와 같이 의도가 드러나도록 이름을 지어야 한다

int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;

다음은 코드가 하는 일을 짐작할 수 있도록 사용하는 예제이다

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[]> flaggedCells = new ArrayList<int[]>();
    for(int[] cell : gameBoard){
    	if(cell[STATUS_VALUE] == FLAGGED){
        	flaggedCells.add(cell);
        }
    }
    return flaggedCells;
}

변수명과 상수를 통해서 조금 더 의도를 파악하기 쉬워졌다

if(cell[STATUS_VALUE] == FLAGGED){
    flaggedCells.add(cell);
}

이 부분을 한번 더 개선하면

if(cell.isFlagged()){
    flaggedCells.add(cell);
}

isFlagged라는 좀 더 명시적인 함수를 사용해 FLAGGED 상수를 감출 수 있다

2. 그릇된 정보를 피해라

프로그래머는 코드에 그릇된 단서를 남겨서는 안 된다

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

나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안 된다

예를 들어 프로그래머에게 List라는 단어는 특수 한 의미다

실제 타입이 List가 아니라면 accountList 보다는 accountGroup, bunchOfAccount, Accounts 등으로 사용하는 것이 바람직하다

(실제 컨테이너가 List인 경우라도 컨테이너 유형을 이름에 넣지 않는 편이 바람직하다. 추 후 나올 내용이라고 함)

서로 흡사한 이름을 사용하지 않도록 주의한다

XYZControllerForEfficientHandlingOfStrings

XYZControllerForEfficientStorageOfStrings

(책에서는 두 단어가 비슷하여 헷갈린다고 표현함. 이 부분은.. 잘 모르겠다 Handling과 Storage부분만 다르기 때문에 유사하다고 하는 것인지 두 단어가 유사한 의미를 지닌다는 것 인지... 이해가 잘 되지 않음)

유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다

일관성이 떨어지는 표기법은 그릇된 정보다

요즘은 코드 자동 완성 기능을 제공하기 때문에 후보 목록에 유사한 개념이 알파벳 순으로 정렬돼서 나오기 때문에 개념 차이가 명백히 드러나는 이름을 사용한다면 굉장히 유용하게 사용할 수 있음!

이름으로 그릇된 정보를 제공하는 끔찍한 예가 소문자 L이나 대문자 O변수다

L은 숫자 1처럼 보이고(I 처럼도 보일 것 같다) O는 숫자 0처럼 보인다

명확히 구분되는 폰트를 사용하는 방법도 있지만 이름 자체를 바꿔서 일거리를 줄이자

3. 의미 있게 구분하라

연속된 숫자를 붙이는 방식은 적절하지 못하다

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

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

불용어(noise word)를 추가하는 방식 역시 적절하지 못하다. 아무런 정보를 제공하지 못함

Product라는 클래스가 있다고 가정했을 경우

다른 클래스를 ProductInfo, ProductData라 부른다면 개념을 구분하지 않고 이름만 다르게 선언한 경우이다

Info나 Data는 a, an, the와 마찬가지로 의미가 불분명한 불용어이다

a나 the와 같은 접두어를 사용하지 말라는 의미는 아니다

의미가 분명히 다르다면 사용해도 무방하다

예를 들어 모든 지역 변수는 a를 사용하고, 모든 함수 인수는 the를 사용하는 등의 경우!

정리하자면 zorz라는 변수가 있다고 해서 theZorz라 이름을 지어서는 안 된다는 말이다

불용어는 중복이다. 변수 이름에 variable이라는 단어는 단연코 금불이다. 표 이름에 table도 마찬가지

NameString이 Name보다 뭐가 나은가? Name이 부동소수가 될 가능성이 있던가?

그렇다면 앞서 언급한 "그릇된 정보를 피하라" 규칙을 위반한다.

코드를 읽다가 Customer라는 클래스와 CustomerObject라는 클래스를 발견했다면 차이를 알 수 없다

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

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

발음하기 어려운 이름은 토론하기도 어렵다

예를 들어 genymdhms (generate date, year, month, day, hour, minute, second) 라는 이름을 사용했다면

어떻게 발음해야 할까? 젠와이엠디에이취엠에스, 젠야무다힘즈 등 우스꽝스러운 상황이 연출될 것이다

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";
    /* ... */
}

발음하기 쉬운 이름은 중요하다. 프로그래밍은 사회 활동이기 때문이다

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

문자 하나를 사용하는 이름과 상수는 찾기가 굉장히 어렵다

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;
}

WORK_DAYS_PER_WEEK 와 같이 상수를 활용하면 5가 들어가는 이름을 모두 찾은 후 코드를 분석하는 것보다 훨씬 검색하기 쉬워진다

6. 인코딩을 피해라

과거에는 컴파일러가 타입을 점검하지 않아서 프로그래머가 코딩할 때 타입을 기억할 단서가 필요했기 때문에

헝가리안 표기법 등을 사용해서 인코딩 정보를 남겨야 했다

https://namu.wiki/w/%ED%97%9D%EA%B0%80%EB%A6%AC%EC%95%88%20%ED%91%9C%EA%B8%B0%EB%B2%95

하지만 현재의 언어는 많은 타입을 지원하고, 컴파일러가 타입을 기억하고 강제한다. 심지어 IDE는 코드를 컴파일하기 전에 타입 오류를 감지할 정도로 발전했다

그러므로 인코딩 방식은 오히려 코드를 읽는데 방해가 되고, 타입을 변경해야 할 때도 문제가 되므로 사용하지 않는 것이 좋다

7. 클래스, 메서드 이름

클래스 이름과 객체 이름은 명사나 명사구가 좋다

좋은 예: Customer, WikiPage, Account, AddressParser 등

나쁜 예: Manager, Processor, Data, Info 등

메서드 이름은 동사나 동사구가 좋다

postPayment, deletePage, save 등

접근자, 변경자, 조건자는 javabean 표준에 따라 값 앞에 get, set , is를 붙인다

생성자(Constructor)를 중복정의(Overload)할 때는 정적 팩토리 메서드를 사용

메서드는 인수를 설명하는 이름을 사용한다

Complex fulcrumPoint = new Complex(23.0);

보다는 아래 코드와 같이 사용하는 것을 권장함

Complex fulcrumPoint = Complex.FromRealNumber(23.0);

생성자 사용을 제한하려면 해당 생성자를 private로 선언하면 된다

8. 기발한 이름은 피하고 말장난을 하지 마라

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

똑같은 메서드를 클래스마다 fetch, retrieve, get으로 제각각 부르면 혼란스럽고 어느 클래스에서 어느 이름을 썼는지 기억하기 어렵다

일관성 있는 어휘를 사용하자!

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

코드를 읽을 사람도 개발자라는 사실을 기억하자

그러므로 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다

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

적절한 프로그래머 용어가 없다면 문제 영역에서 이름을 가져온다

그러면 코드를 보수하는 개발자가 해당 분야 전문가에게 의미를 물어 파악이 가능하다

우수한 개발자와 설계자라면 해법 영역과 문제 영역을 구분할 줄 알아야 한다

문제 영역 개념과 관련된 깊은 코드라면 문제 영역에서 이름을 가져와야 한다

12. 의미 있는 맥락을 추가하라

firstName, lastName, street, gouseNumber, city, state, zipcode 라는 변수가 있다

변수를 훑어보면 주소라는 사실을 알아챌 수 있다

하지만 state 하나의 변수만 사용한다면 주소의 일부라는 사실을 바로 알아차리긴 쉽지 않다

addr라는 접두어를 추가한다면 addrFirstName, addrLastName, addrStreet, addrState...... 등 맥락이 좀 더 명확해진다

물론 Address라는 클래스를 생성하는 것이 더 좋다!

13. 불필요한 맥락을 없애라

고급 휘발유 충전소 (Gas Station Deluxe)라는 애플리케이션을 짠다고 가정했을 때 모든 클래스 이름을 GSD로 시작하겠다는 생각은 바람직하지 않다

IDE에서 G를 입력하고 자동완성 키를 누르면 모든 클래스가 GSD로 시작하기 때문에 전부 검색될 것이다

이처럼 이름에 불필요한 맥락을 추가하지 않도록 주의하자

다른 예로

accountAddress와 customerAddress는

Address 클래스 인스턴스로 좋은 이름이지만 클래스 이름으로는 적합하지 않다

Address는 클래스 이름으로 적합하다

마무리 느낀 점

컬럼명, 변수명, 클래스명 등을 지을 때마다
"이름을 뭐라고 지어야 되지.." 하는 고민은 많은 개발자들이 공감할 것이다
물론 나는 저렇게 구체적인 규칙을 생각하면서 고민을 하지는 못했다
이런 것도 생각하면서 네이밍을 하는구나 를 굉장히 많이 느꼈다
이런 규칙들을 생각하면서 네이밍을 한다는 사실을 알고 편해진 것 같으면서도 한편으로는 더 어려워진 것 같은 기분이다
영어가 모국어가 아니기 때문에 책의 내용을 완벽히 적용시키는 데는 어려운 점이 많겠지만 노력해봐야겠다