Kiyeon

Backend developer

2 minute read

깨끗한 코드, 가독성이 좋은 코드는 좋은 개발자?를 판단하는 수많은 기준중 한가지라고 생각한다. Clean Code 책을 하루에 얼마나 읽을 수 있을지는 모르겠지만, 책을 읽으며 내용을 정리해 보았다.

의도를 분명히 밝혀라

내가 작성한 코드는 나만 보는것이 아닐 것이다. 주석을 달지 않아도 변수, 함수, 클래스명을 나타낼 수 있는 네이밍을 사용하자

그릇된 정보를 피해라

그릇된 단서는 코드의 의미를 흐린다. 유사한 개념은 유사한 표기법을 사용한다. 실제로도 자바에서 제공하는 자동완성 기능을 사용할때 각 함수의 주석을 들어가 파악하기 보다는 이름을 보고 파악한다.

의미있게 구분하라

컴파일러를 통과할 지라도 연속적인 숫자를 덧붙이거나 불용어를 추가하는 방식은 적절하지 않다 ex) a1, a2, a3…

public static void copyChars(char[] a2, char[] a2) {
    for(int i = 0; i< a1.length ; i++) {
        a2[i] = a1[i]
    }
}
  • 개선 하기 전
public static void copyChars(char[] source, char[] destination) {
    for(int i = 0; i< source.length ; i++) {
        destination[i] = source[i];
    }
}
  • 개선 후 (함수 인수 이름 변경)

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

사람들은 단어에 익숙하다. 그리고 단어는 발음이 가능하다. 그러므로 발음하기 쉬운 이름을 선택하자 간단한 메서드에서 로컬 변수만 한 단어를 사용한다. 변수나 상수를 코드 여러곳에서 사용한다면 검색하기 쉬운 이름을 사용하자

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 += realTaskWeelks;
}
  • 개선후 (검색하기 쉬운 경우)

인코딩을 피하라

예전에는 필요할 수 있었으나, 최근에는 컴파일러가 타입을 기억하고 강제한다. 따라서 이제는 헝가리식 표기법이나 기타 인코딩 방식이 오히려 방해가 될 뿐이다. 인터페이스 클래스와 구현 클래스와 같이 필요한 경우에는 구현 클래스 이름을 택하는게 가독성이 좋을 수 있다.

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

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

클래스 이름

명사 혹은 명사구가 적합하다. 단, Manager, Processer, Data, Info등과 같은 단어는 피하고, 동사는 사용하지 않는다.

메서드 이름

동사 혹은 동사구가 적합하다. 접근자, 변경자, 조건자는 javabean표준에 따라 get, set, is를 붙이자. 생성자를 overload 할때에는 Static Factory Method 패턴을 이용하자.

Customer customer = Customer.SignInKid("kiyeon", 26); //Static Factory Method

Customer customer = new Kid("kiyeon", 26); // Constructor

ex) Kid Class가 Customer Class를 상속하고 있다 가정

기발한 이름 보다는 명료한 이름을 선택해라

의도를 분명하고 솔직하게 표현할 수 있는 이름을 선택해라.

한 개념에 한 단어 (일관성 있는 어휘)를 사용해라

추상적인 개념 하나에 단어 하나를 선택해 고수해라. 같은 동작을 하는 메서드를 클래스마다 fetch, retrieve, get으로 제각각 부르면 혼란스럽고, 기억하기 어렵다.

말장난을 하지마라

한가지 단어를 두가지 이름으로 사용하지 마라. 다른 개념에 같은 단어를 사용하면 말장난일 뿐이다.

해법영역 혹은 문제영역에서 가져온 이름을 사용해라

코드를 읽을 사람은 프로그래머이다. 적절한 프로그래밍 용어가 없다면 문제영역에서 이름을 선택한다.

의미 있는 맥락을 추가하라

스스로 의미가 분명한 이름이 없지 않다. 그러나 대부분의 이름은 맥락이 없다. 클래스, 함수, 이름 공간에 넣어 맥락을 부여하고 전부 안된다면 마지막 수단으로 접두어를 붙힌다.

불필요한 맥락은 없애라

일반적으로 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다. accountAddress와 customerAddress는 Address 클래스 인스턴스로는 좋은이름이나, 클래스 이름으로는 적합하지 못하다.

2장을 읽으며..

기존 코드를 작성중 어떤 방식이 더 나을까, 어떻게 작성시 가독성이 좋을까란 생각을 하고 이책을 읽기 시작했다.
마치면서의 글중 사람들이 이름을 바꾸지 않으려는 이유 하나는 다른 개발자가 반대할까 두려워서 이와 같은 생각도 있었으나 오히려 반갑고 고맙다는 글이 매우 인상적으로 다가왔다.
더 좋은 코드를 짜기위해 고민해보아야겠다.

Leave a comment

You may also enjoy