클린 코더스 강의 요약(Form) - 4

주석

1. 의미 없는 주석은 되도록 작성하지말자 (형식적인 주석)

// 의미 없는 주석의 예
/**
 * Set a configuration property
 * @param key the property key
 * @param value th property value
 */
 public void setConfigProperty(final String key, final String value) {
 	// ...
 }

2. 주석을 읽는 모든 사람들이 감사한 마음을 가질 수 있어야 한다

3. 주석을 함수의 이름에 잘 녹여낼 수 있도록 하자(물론 Assembly 언어는 불가능)

4. 보통의 개발자들이 작성하는 주석은 함수명으로 녹여낼 수 있고, 주석은 작성자의 코드의 표현력이 충분하지 못하다는 반증이 되기도 한다.

 

좋은 주석?

라이센스를 표현하는 주석, 정규식 파싱 예시 주석, 정말 오래 걸리는 메서드 등에 대한 경고, TODO 등 IDE 에서 제공해주는 코멘트, Public API Documentation (Third party 로 제공 등)

 

나쁜 주석이 될 수 있는 것들?

중복 표현(메서드에 이미 표현이 되어있는데, 다시 주석을 다는 경우 위의 1번과 동일), 파라미터관련 자동 생성 주석, 변경 이력 주석(GIT, SVVN 에서 해결 가능), 문법 설명에 대한 주석, /************주석 설명 *******/ 과 같은 주석, Scope 의 끝을 알려주는 주석(end of if, end of while 등 - 전혀 감사하지 않은 주석), written by 같은 주석, 함수 보다 더 큰 정보를 담는 주석 등

 

Vertical Formatting(세로 공란을 잘 표현하여 생산성을 올리자)

- 메서드 사이는 엔터

- Private, Public 변수들 사이는 엔터

- 변수 선언과 메서드 실행(구현)부분 사이는 엔터

- 서로 관련된 것들은 Vertical 하게 작성되어 있어야한다.(Vertical 거리가 그들간의 관련성을 나타낸다)

 

클래스 관련

 외부에서는 Private 변수들이 없는 것 처럼 보여야한다.(But getter/setter 로 인해 보이게 되는 문제가 있어 최대한 지양하는 것이 좋음)

위와 같이 생긴 클래스가 있다면 우리는 분명 getGallonsOfGas 같은 메서드를 만들어서 제공할 확률이 높다.(아래 이미지 처럼)

getGallonsOfGas 메서드를 gallonsOfGas 라는 변수가 있다는 것을 쉽게 알 수 있게 되어 내부를 드러내고 있다.

또한 DieselCar 가 Car 클래스를 상속 받는다고 가정하면, 디젤차가 마치 가솔린을 사용하는 것과 같은 모순을 만들어 낸다

그렇게 때문에, 추상화를 통해 제공하는 방식을 사용하면 좋다.

가령 getPercentFuelRemaining() 같은 메서드로 남아있는 연료가 얼마인지 제공하는 메서드를 활용한다면, 경유, 휘발유 등 스스로 구현해야 사용할 것이니, 앞의 문제가 해결된다. 또한 캐스팅해서 메서드에 접근하는 등의 문제도 해결된다.(폴리모피즘은 이미 이전에 많이 이야기해서 패스합니다)

 

Data structures(변수의 집합 - 메서드가 존재하지 않음)

- Public 변수들 + getter/setter

- 대부분 Type 에 의존하는 코드가 많이 나오기 때문에 타입 비교, 캐스팅 등으로 코드가 늘어나고 if, switch case 가 늘어난다 (클래스는 Extends, Implementation 으로 해결할 수 있음) 

 - 클래스는 타입 추가에 유연하고, DataStructure 는 기능 추가에 유연함(visitor 디자인 패턴을 이용하여 클래스는 기능 추가에도 유연하게 대응 가능)