Chapter 3. 함수
작게 만들어라!
if 문/else 문/while 문 등에 들어가는 블록은 한 줄이어야 한다
중첩 구조가 생길만큼 함수가 커져서는 안된다. 그러므로 함수에서 들여쓰기 수준은 1단이나 2단을 넘어서면 안 된다.
한가지만 해라!
함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다.
💡 함수 당 추상화 수준은 하나로!
함수가 확실히 '한가지' 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 한다.
ex) 좋은 예
public static String renderPageWithSetupsAndTeardowns(
PageData pageData, boolean isSuite) throws Exception {
if (isTestPage(pageData))
includeSetupAndTeardownPages(pageData, isSuite);
return pageData.getHtml();
}함수 인수는 0개가 가장 좋다
함수에서 이상적인 인수 개수는 0개다. 다음은 1개, 2개다. 3개는 가능한 피하는 편이 좋다.
Chapter 3. 함수 부분이 이해하기 가장 어려웠다 😥😥😥 감은 오는데 신경써서 짤 수 있을까 하는... 읽고 나니까 나는 함수 하나에 모든 내용을 다 담았는데 생각하지 않고 짰구나 라는 생각이 들었다 ...
Chapter 4. 주석
우리는 코드로 의도를 표현하지 못해, 그러니까 실패를 만회하기 위해 주석을 사용한다. 때때로 주석 없이는 자신을 표현할 방법을 찾지 못해 할 수 없이 주석을 사용한다. 우리는 (간혹 필요할지라도) 주석을 가능한 줄이도록 꾸준히 노력해야 한다.
주석은 나쁜 코드를 보완하지 못한다!
코드에 주석을 추가하는 일반적인 이유는 코드 품질이 나쁘기 때문이다. 자신이 저지른 난장판을 주석으로 설명하려 애쓰는 대신에 그 난장판을 깨끗이 치우는데 시간을 보내자
하지만 모든 주석이 다 나쁘다는 건 아니다! 어떤 주석은 필요하거나 유익하다
💡 좋은 주석
- 정보를 제공하는 주석 : 때때로 기본적인 정보를 주석으로 제공하면 편리하다
// 테스트 중인 Responder 인스턴스를 반환한다.
protected abstract Responder responderInstance();
-
의도를 설명하는 주석 : 때로는 주석은 구현을 이해하게 도와주는 선을 넘어 결정에 깔린 의도까지 설명한다.
-
의미를 명료하게 밝히는 주석 : 때때로 모호한 인수나 반환 값은 그 의미를 읽기 좋게 표현하면 이해하기 쉬워진다.
-
TODO 주석 - '앞으로 할 일'을 //TODO주석으로 남겨두면 편리하다.
💡 나쁜 주석
- 같은 이야기를 중복하는 주석 - 코드를 정당화하는 주석도 아니고, 의도나 근거를 설명하는 주석도 아니다. 코드보다 읽기가 쉽지도 않다.
/**
* 이 컴포넌트의 프로세스 지연 값
*/
protected int backgroudProcessorDelay = -1;-
의무적으로 다는 주석 - 모든 함수에 Javadocs를 달거나 모든 변수에 주석을 다는 규칙은 어리석기 그지없다.
-
함수나 변수로 표현할 수 있다면 주석을 달지 마라
-
주석으로 처리한 코드 - 주석으로 처리된 코드는 다른 사람들이 지우기를 주저한다. 이유가 있어 남겨 놓았으리라고 지우면 안 된다고 생각한다. 그래서 쓸모없는 코드는 점차 쌓여간다.
❗ 출처
📖 클린코드 - 로버트 C. 마틴 저자
