깨끗한 코드 만들기

깨끗한 코드 만들기

 

깨끗한 코드 (클린 코드, Clean Code) from Jay Park

 

가독성의 기본
1. 코드는 이해하기 쉬워야 한다.
2. 코드는 다른 사람이 그것을 이해하는 데 들이는 시간을 최소화하는 방식으로 작성되어야 한다.
3. 1회용 코드는 되도록 피해야 한다(스스로가 희생양이 될지도).
참고: Perl 코드(WORN: Write Once Read Never)

코드 읽기 vs 코드 쓰기
읽기: 쓰기의 비율은 읽기 = 10: 쓰기 = 1
비율이 이렇게 높으므로 읽기 쉬운 코드가 매우 중요하다. 비록 읽기 쉬운 코드를 짜기가 쉽지는 않더라도 말이다. 하지만 기존 코드를 읽어야 새 코드를 짜므로 읽기 쉽게 만들면 사실은 짜기도 쉬워진다.
이 논리에서 빠져나갈 방법은 없다. 주변 코드를 읽지 않으면 새 코드를 짜지 못한다. 주변 코드를 읽기가 쉬우면 새 코드를 짜기도 쉽다. 주변 코드를 읽기가 어려우면 새 코드를 짜기도 어렵다. 그러므로 급하다면, 서둘러 끝내려면, 쉽게 짜려면, 읽기 쉽게 만들면 된다.

현실에서는 ? 데이비드 파나스(소프트웨어 공학 태두)
소프트웨어 설계자가 요구 사항으로부터 이성적이고 오류가 없는 방식으로 설계한 그림은 엄청나게 비현실적입니다. 어느 시스템도 이런 이성적인 방식으로 개발되지 않았으며, 아마도 앞으로도 이런 일은 생기지 않을 것입니다. 심지어 교과서나 논문에 나온 작은 프로그램 개발조차도 비현실적입니다. 교과서나 논문에 나온 프로그램은 개선되고 수정되는 과정을 거치면서 저자들이 바라는 바를 보여주지 실제 일어난 과정을 보여주지는 않습니다.

단위 테스트 실행시 지켜야할 원칙 : F.I.R.S.T.
빠르게(Fast): 테스트는 빨라야 한다.
독립적으로(Independent): 각 테스트는 서로 의존하면 안 된다. 한 테스트가 다음 테스트가 실행될 환경을 준비해서는 안 된다.
반복가능하게(Repeatable): 테스트는 어떤 환경에서도 반복 가능해야 한다.
자가검증하는(Self-Validating): 테스트는 부울(bool) 값으로 결과를 내야 한다. 성공 아니면 실패다.
적시에(Timely): 테스트는 적시에 작성해야 한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.

이름 짓기
1. 수학 함수라고 해서 어려울 필요는 없다. i)함수 포인터 타입 정의 ii) 좌표를 구조체로
2. 표현을 잘개 쪼개기.
 - 거대한 표현을 작은 조각으로 나누고 함수로 분리한다.
 - 하위표현을 간결한 이름으로 대체해 함수로 분리한다.
 - 코드를 읽는 사람이 핵심 ‘개념’을 파악하게 읽기 쉬운 코드를 작성한다.
3. 변수는 내버려두면 계속 늘어난다. 변수를 덜 사용하고 최대한 ‘가볍게’ 만들어 가독성을 높인다. 아래와 같이 실천한다.
 - 방해되는 변수를 제거: 결과를 즉시 처리하는 방식으로, 중간 결과값을 저장하는 변수를 제거
 - 각 변수의 범위를 최대한 작게 줄임: 각 변수 위치를 옮겨 변수가 나타나는 줄의 수를 최소화.

    안 보이면 멀어진다.
 - 값이 한번만 할당되는 변수를 선호: const, final 등으로 값이 한 번만 할당되어 바뀌지 않는(즉 불변)

    변수는 이해하기 쉽다.

코드 흐름 제어 : 코드 흐름을 읽기 쉽게 만들어야 논리가 명확해진다. 아래와 같이 실천한다.
 - if/else문의 블록 순서에 주의: 긍정적이고 쉽고 흥미로운 경우가 앞쪽에 위치
 - 삼항연산자(: ?)나 do/while, goto는 코드 가독성을 떨어뜨리므로 되도록 사용 금지
 - 중첩된 코드 블록의 흐름을 따라가려면 많은 집중이 필요하다  선형적인 코드 추구
 - 함수 중간에 반환하면 중첩을 피하고 코드를 더 깔끔하게 작성 가능하다. 

   함수 앞부분에서 ‘보호 구문’으로 간단한 경우를 미리 처리하는 방안도 고려
 

켄트 백의 간단한 설계 규칙 네 가지
모든 테스트를 실행한다.
중복을 없앤다.
프로그래머 의도를 표현한다.
클래스와 메소드 수를 최소로 줄인다.

 

 

 

.