주석은 나쁜 코드를 보완하지 못함 표현력 풍부, 깔끔, 주석 거의 없는 코드 >>>>> 복잡, 어수선, 주석 많이 달린 코드 코드로 의도 표현하기 코드만으로 의도 설명하기 어려운 경우 존재함 != 코드는 훌륭한 수단이 아님 //직원에게 복지 혜택 받을 자격 있는지 검사 if((employee.flags & HOURLY_FLAG) && (employee.age>65) if(employee.isEligibleForFullBenefits()) 주석으로 달려는 설명을 함수로 만들어 표현하기 좋은 주석 법적인 주석 ex) 각 소스 파일 첫머리에 주석으로 들어가는 저작권 정보, 소유권 정보는 필요함 모든 조항, 조건 열거하는 대신 표준 라이센스나 외부 문서 참조해도 됨 정보 제공하는 주석 때로는 기본적인 정보를 주..
작게 만들기 블록, 들여쓰기 if/else문, while문 등에 들어가는 블록은 한 줄이어야 함 - 보통 여기서 함수 호출함 (감싸는 함수도 작아지고 코드 이해도 쉬워짐) 중첩 구조 생길만큼 함수 커지면 안됨 (들여쓰기 수준은 1,2단 넘으면 안됨) 하나만 하기 함수는 한 가지만을 잘 해야 함 지정된 함수 이름 아래에서 추상화 수준 하나인 단계만 수행 - 한 가지 작업만 하는 것 의미 있는 이름으로 다른 함수 추출 가능 - 그 함수는 여러 작업 하는 것 함수 당 추상화 수준 하나로 할 것 함수가 확실히 '한 가지' 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 함 추상화 수준 getHtml() - 아주 높음 String pagePathName = PathParser.render(pagepat..
이름 잘 짓는 규칙 의도 분명히 밝히기 따로 주석이 필요 없을 정도로 변수의 존재 이유 수행 기능 사용 방법 그릇된 정보 피하기 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하면 안됨 - hp, aix, sco (유닉스 플랫폼이나 변종 가리키는 이름이라 사용하면 안됨) 실제 List가 아니면 accountList라고 명명하지 않음 - 계정 담는 컨테이너가 실제 List가 아니면 안됨 - accountGroup, bunchOfAccounts, Accounts 라 명명할 것 - 실제 컨테이너가 List라도 컨테이너 유형을 이름에 안 넣는게 좋음 서로 흡사한 이름 사용하면 안됨 유사한 개념은 유사한 표기법 사용할 것 일관성 떨어지는 표기법은 그릇된 정보임 의미 있게 구분하기 컴파일러나 인터프리터만 통과하려..
나쁜 코드를 짜면 계속해서 나쁜 코드를 짜게 되고 결국 효율성이 극도로 떨어져서 0에 수렴하게 됨 코드 읽는 시간과 짜는 시간 비율이 10 대 1을 훌쩍 넘겨서 처음부터 코드를 잘 짜야 함 체크아웃할 때보다 좀 더 깨끗한 코드를 체크인한다면 코드는 절대 나빠지지 않음 -> 변수 이름 하나 개선, 조금 긴 함수 하나 분할, 약간의 중복 제거, 복잡한 if문 하나 정리하는 것으로 충분함 이 책은 Agile Software Development: Principles, Patterns, and Practices (PPP)의 프리퀄임 PPP에서 설명하는 다섯 가지 원칙 SRP (The Single Responsibility Principle) : 클래스에는 단 한가지 변경 이유만 존재해야 함 OCP (The Op..
