클린코드 정리

클린코드 정리해보기

클린코드 글을 보고 정리해둡니다. 프로젝트 들어가기 전에 한번씩 읽어보면 잔상이 남아서 좋지 않을까 생각합니다.

• Naming
• 함수
• 그 외

Naming

1. 풀네임으로 작성할것

2. 함수라면 return 값을 보고 관련 이름으로 정할 것

3. 타입 정보는 불필요 ( 타입스크립트의 도움을 받을 수 있으며 타입이 변경될 때마다 변수명도 변경해야 하기에 애매함 )

4. 중복된 단어는 제거. 완벽함이란 더이상 더할 것이 없는 게 아니라, 무언가를 더이상 뺄 것이 없는 것이다 -생텍쥐페리

5. 사용하려는 전문 용어가 다른 단어로 대체 불가할 때만 사용

6. 단어의 뉘앙스를 고려 (ex_ get , find)

7. 기존팀내 규칙이 좋지 않더라도 따르는 어느정도 유연한 자세 필요 ( 개선은 그 다음 )

8. 함수는 동사로 시작하여 명사로 끝 ( is, exists, has, use ), boolean 반환 함수는 부정보다는 긍정문으로 작성

9. 클래스나 인스턴스 변수명은 명사형, 클래스의 경우 '무엇을 어떻게 하는가' 까지 구현하면 좋음

(ex_ destinationAddress)

함수

1. 작은 함수 지향, 쪼개기 부담스러울 땐 클래스의 역할이 너무 많은 것이 아닌지 점검

- 유지 보수가 훌륭한 프로그램은 공통적으로 **함수가 15줄 이상 되지 않음**

- 에디터의 수직, 수평 스크롤 고려

2. 하나의 함수에 하나의 일만 작성

- 추상화 되면 하나의 함수에 많은 일을 하게 됨. 따라서 **제한적이고 구체적으로 함수를 작성**

3. 만능 API 가 되지 않도록 형식에 엄격한 제한 - 선 엄격 제한, 후 다양한 입력 형식으로 확장

4. 추상화 수준이 같이 않은 함수는 일관되게 맞춤.

 

1 2 3 4 5 6 7 8 9 10 11 12 13

function validateAndReport() {     validate();          Reporter = new Reporter;     const obj = []; }     // 추상화 수준을 일괄적으로 변경 function validateAndReport() {     validate();     report(); }

cs

 

6. 중괄호는 지양. 두단계 이상의 depth는 지양.

7. 매개 변수 개수는 적을수록 좋음. 같은 타입이 연속되면 버그를 일으킬 가능성이 높음.

8. if문 boolean 함수는 지양 - 매서드가 어떻게 동작하는지 어려움이 있음, 각각의 경우 함수를 따로 정의, else를 지움

9. 유효성 검사는 철저히 - null 값 지양

10. 방어적 복사본 반환

11. 위에서 아래로 자연스럽게 읽혀야 함 - 두 함수가 있고 이를 호출하는 함수는 각각이 아닌 두 함수의 아래 위치 (선 팀내 규칙 따르는 방향)

12. public 함수는 맨 위로 (InttelliJ 스트럭쳐 뷰 기능(command + 7)) - public 함수는 how가 빠지는 것이 좋음

13. 변수, 함수, 클래스가 넓은 범위로 사용되고 자주 호출된다면 이름은 짧을수록 좋음 ( 하지만 하위 클래스가 많다면 충분히 서술해주어야 함 )

그 외

1. 인트 타입의 상수는 지양 (ex. if(productNum == "s201") )

2. 이미 개발된 기능을 만드는 데 시간을 쓰지 말 것

3. 작은 리팩터링부터 제안 (받아들여질 가능성이 커짐)

4. 동료들이 인지 할 수 있는 문제 제안

5. 현실적 해결책이 바탕 되어야 함

6. 제안 전 리팩터링 기한과 코드 범위 사전 정의

7. 왜 이렇게 했냐는 말보다는 'a보다는 b가 낫지 않을까요'의 형태 제안