[개발서적] Clean Code 정리

1. 의미 있는 이름을 작성하자

누가 보든 알아보기 쉽게 변수명과 함수명을 작성하자
읽기 쉽고, 직관적인 단어를 사용하자(줄임말 말고)
코드 길이가 조금 길어지더라도 상수를 변수로 사용하자(검색의 편의를 위해)
클래스 이름 : 명사/명사구
메소드 이름 : 동사/동사구
한 개념에 한 단어(동의어를 사용하지 말 것)​

 

2. 함수는 작게 작성하자

​최대한 짧게 작성하자.
indent는 1-2개 정도로 두자.
함수 이름을 서술어로 잘 설정해서 코드만 읽어도 이해되게 해 보자.
함수는 1가지 역할만 하자. (추상화 수준을 1개로 만들자는 것)
함수 인수는 최대한 적게 두자.

 

3. 주석은 최대한 없애자

주석이 필요없을 정도로 깔끔한 코드를 짜면 된다.
필요하다면, 의도와 의미를 명확하게 설명하자.
필요한 주석은, 법적문제, 결과 경고, TODO, 강조 등이다.
TODO는 필요하지만 당장 구현하기 어려운 것, 더 좋은 이름을 떠올려달라는 요청, 주의 등에 유용하다.

 

4. 형식 맞추기

변수는 사용하기 직전에 선언하자.
함수 선언 순서는 호출하는 것을 위로 올리자.
다른 개념은 개행으로 분리하자.

 

5. 객체와 자료 구조

getter/setter는 최대한 줄이고, 추상화 정도를 높이자.

 

6. 오류 처리

오류 코드보다 예외처리를 이용하자. (try-catch-finally, else)
null을 리턴하지 말자.

 

7. 단위 테스트

test-driven-development는
 - unit test가 실패할 때 까지 실 코드를 작성하지 않는다(실패하면 그때 작성)
 - 컴파일은 성공, 실행이 실패할 정도로만 unit test를 작성한다.
 - 실패하는 테스트를 통과할 정도로만 실 코드를 작성한다.
라고 한다. -> 모든 함수, 모든 클래스, 모든 메소드가 잘 동작하는지 테스트 코드를 작성하라는 것 아닐까?
테스트 코드도 깔끔하게 작성하자.
테스트 코드 하나당 assert는 1개로 두자. - 테스트 코드 하나당 개념 1개만 테스트하자.

(잘 작성한) 테스트 코드가 있기 때문에, 코드를 수정하더라도 시스템에 문제가 생길까 걱정하지 않아도 된다.

 

8. 클래스

클​래스도 최대한 작게 만든다. - 클래스 이름이 클래스가 어떤 것을 책임지는지 나타낼 수 있게.
single responsibility principle, 단일책임원칙 - 클래스는 1개만 책임진다. - 이걸 위해서 상속받는다. 수정 하기도 편해진다.