summary of chapter 3 in CLEAN CODE.

1. CLEAN CODE

2. 함수를 만드는 규칙 작게 만들어라. 더 작게 만들어라. If 문/ else 문/ while 문에 들어가는 블록은 한 줄로 함수에서 들여쓰기 수준은 1이나 2단으로 한다.

3. 함수는 한 가지만 해야 한다. 그 한 가지를 잘 해야 한다. 여기서 한 가지만 이란 같은 추상화 수준을 의미한다. 한 가지 작업을 수행하는 함수는 섹션으로 분할하기 힘들다.

4. 추상화 수준 높음 getHtml() String pagePathName = PathParser.render(pagePath); .append(“”); 낮음 추상화 수준이 같지 않으면 읽기가 어렵다. 깨진 창문 효과로 인해 코드가 계속해서 나빠질 수 있다.

6. OCP 위반

7. 코드 중복해결책은 ? 다형성을 이용하라!

8. 작은 함수는 서술적인 이름을 고르기 쉽다. 긴 서술적인 이름 > 짧고 어려운 이름 IDE를 이용하라. replace 기능을 이용해서 이런저런 이름을 시도해 보라. 서술적인 이름은 코드 개선에도 도움을 준다. 이름을 지을 때 일관성이 중요하다.

9. 함수의 인수는 적을수록 좋다. 인수가 많으면 테스트 케이스를 작성하기 어렵다. 출력 인수는 입력 인수보다 이해하기 어렵다. 반환값을 기대하지 출력 인수를 기대하지 않는다.

10. booleanfileExists(“MyFile”) 과 같은 조회 InputStreamfileOpen(“MyFile”) 과 같은 명령 두 형식은 단항 함수가 당연하다. 시스템의 상태를 바꾸는 이벤트 함수도 단항 함수로 괜찮다.

11. 플래그 인수는 추하다. 함수가 여러 가지를 처리한다고 공표하는 것과 같다. renderForSuit() renderForSingleTest() < render(booleanisSuite)

12. writeField(name) vswriteField(outputStream, name) 어느 쪽이 이햐하기 쉬운가? 이항 -> 단항으로 변환을 할 수 있다면 그렇게 하자. 이항 인수가 적절한 경우도 있다. EX) Point p = new Point(0, 0) vs Point p = new Point(0) 만약 두 인수가 한 가지 값을 표현하거나 자연적인 순서가 있다면 OK assertEquals(expected, actual) 과 같이 당연한 이항 함수도 자연적인 순서가 존재하지 않아서 실수를 유발한다.

13. Difficulty 삼항 함수 >이항 함수 assertEqual(message, expected, actual) 첫 번째 인수가 expected라고 예상하지 않았나? 예외) assertEqual(1.0, amount, 0.001) 이해하기는 어렵지만, 부동소수점의 정밀도를 고려하면 가치는 있다.

14. Circle makeCircle(double x, double y, double radius); vs Circle makeCircle(Point center, double radius); 같은 개념의 인수를 새로운 객체로 합칠 수 있는지? 확인하자!

15. String.format, printf와 같이 가변 인수가 필요한 경우가 있다. 가변 인수를 한 개의 인자로 생각할 때 마찬가지로 함수의 인자 수가 삼항을 넘으면 안된다.

16. 함수의 의도를 표현하기 위해서 좋은 이름은 필수적이다. 단항 함수는 함수와 인수 -> 동사/명사로 EX) write(name), writeField(name) 또 함수 이름에 키워드를 추가할 수도 있다. EX) assertEquals < assertExpectedEqualsActual(expected, actual) 이렇게 함으로써 인수의 순서 문제를 해결할 수 있다.

17. 부수 효과는 함수가 한 가지 일만 수행한다는 원칙을 위배한다. 부수 효과로 인해 일시적인 결합이나 순서 종속성이 생긴다. 때로, 일시적인 결합이 필요하다면 함수 이름에 명시하자. 물론 함수가 한 가지만 한다는 규칙을 위반하지만 말이다.

18. 출력 인수를 피하라! 출력 인수는 코드 읽기의 흐름을 망해한다. OOP이전에는 출력 인수가 필요했다. 하지만 OOP에선 this가 출력 인수를 대신한다.

19. If( set(“username”, “unclebob”) ) /*…*/ 확인 or 설정 ? If( attributeExists(“username”) ) { setAttribute(“username”, “unclebob”); /*…*/ } 명령과 조회를 구분하자.

20. 오류 코드를 반환하는 함수도 명령/조회의 규칙을 위반한다. EX) If( deletePage(page) == E_OK ) { if( registry.deleteReference(page.name) == E_OK ) { if( configKeys.deleteKey(page.name.makeKey()) == E_OK ) { logger.log(“page deleted”); } else { logger.log(“configKey not deleted”); } } else { logger.log(“deleteReference from registry failed”); } } else { logger.log(“delete failed”); return E_ERROR; }

21. 예외를 사용하면 오류 처리 코드가 원래 코드에서 분리된다. EX) try { deletePage(page); registry.deleteReference(page.name); configKeys.deleteKey(page.name.makeKey()); } catch(Exception e) { logger.log(e.getMessage()); }

22. 오류 처리도 한 가지 작업이므로 try/catch 블록을 별도의 함수로 뽑아내면 코드가 더 보기 좋아진다. EX) public void delete(Page page) { try { deletePageAndAllReference(page); } catch(Exception e) { logError(e); } }

23. 오류 코드도 OCP를 위반한다. 오류 코드를 추가하려면 코드를 수정해야 한다. DRY Don’t Repeat Youself. 반복을 하지 말자! 중복은 오류의 원천이다.

24. 함수를 만드는 작업은 일련의 제련 과정이다. 첫 술에 배부르랴! 점차적으로 Refactoring하자. 하지만 테스트가 없다면 이런 과정은 불가능하다.

25. 좋은 함수를 작성하는 것도 중요하지만 진짜 목표는 시스템이라는 이야기를 풀어가는데 있다는 것을 잊지말자!

26. 끝