클린코드(Clean Code)

 

 

나는 우아하고 효율적인 코드를 좋아한다. 논리가 간단해야 버그가 숨어들지 못한다. 

의존성을 최대한 줄여야 유지보수가 쉬워진다. 오류는 명백한 전략에 의거해 철저히 처리한다.

성능을 최적으로 유지해야 사람들이 원칙 없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다.

-비야네 스트롭스트룹(C++창시자)

 

클린코드는 한 가지를 제대로 한다. 

훌륭한 프로그래머는 사람이 이해할 수 있는 코드를 짠다. 

클린코드는 단순하고 직접적이다. 

특정 목적을 달성하는 방법은 하나만 제공한다.

클린코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다.

코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 클린코드라 불러도 되겠다.

 

소프트웨어 대가들이 정의한 클린코드를 살펴보면, 공통적으로 지적하는 것이 있다.

코드를 작성한 의도와 목적이 명확하며 다른 사람이 쉽게 읽을 수 있어야 한다는 점이다.

 

---

클린코드란?

"모든 팀원이 이해(understandability)하기 쉽도록 작성한 코드"

 - 의존성이 적어 단순하고, 테스트코드로 검증된 코드

 - 코드를 해석하는 시간과 수정하는 시간의 비율은 10(read) : 1(writer)

 - 대부분의 결함은 기존 코드 수정 시에 발생되므로 이해하기 쉬운 코드는 오류의 위험을 최소화한다.

 

클린코드의 필요성

개발자가 새로운 기능을 추가하거나 수정하기 위해 코드를 읽고 쓰는 비율을 따져본다면 읽기 : 쓰기 10:1에 달한다.

개발시간을 단축할 수 있는 좋은 방법이 처음부터 읽기 쉬운 코드를 짜는 것이다.

 

보이 스카우트 규칙

캠핑장을 떠나기전에 원래보다 깨끗하게 해야한다

(참조되거나 수정되는 코드는 원래보다 clean하게 해야 한다.)

다음 사람(인수인계, 부서 내 순환 등)에게 넘겨줄때 조금 더 코드를 클린하게 바꿔 보기 쉽도록 하는 것.

 

---

1. Naming

의미 있는 이름을 사용하자

 

나쁜 예

좋은 예

 

2. Style

적절한 행 길이와 들여 쓰기를 유지하고, 개념은 빈행으로 분리하라.

변수는 사용하는 위치에 최대한 가까이 선언하고, 

종속관계의 함수는 세로로 가까이 배치하라.

 

3. 주석

주석으로 나쁜 코드를 보완하지 말고, 코드로 의도를 표현하라.

 

코드로 설명할 수 있기 때문에 주석이 필요 없다.

 

나쁜 예

 

위의 세가지의 행위의 의미를 파악하라.

 

좋은 예

 

4. Dead Code

사용하지 않는 코드

if문에서 else가 의미 없는 코드

개발하는 과정에서 코드를 주석처리하고 남겨두는 것(언젠가는 쓰겠지 하는 생각들..)

 

5. Method

함수에서 인수의 개수는 적을 수록 좋다.

매개변수는 최대한 줄여라.

최대한 단순하게 처리하자

 

코드를 기계적으로 짜지말고 알고리즘을 생각하라.

 

나쁜 예

 

단일 역할을 수행하도록 한다. 의도하지 않는 결과를 초래하지 않도록 하자.

 

좋은 예

 

함수명을 위드하이폰을 붙여 명확하게 한다.

 

나쁜 예

 

 

두 개의 기능을 분리해서 별도의 함수를 가져간다

 

나쁜 예