매우 읽기 편한 코드를 작성하기 위한 가이드
- 가독성: 코드를 자유롭게 수정하고, 버그를 찾고, 수정된 내용의 상호작용을 이해하기 위한 시간을 짧게 하기 위해 수정되어야 한다
- 표면적 수정
- 가장 쉬운 수준에서의 개선으로 수정 반영이 매우 쉽고 효과적이다
- 이름에 정보 담기
- 보편적인 이름(tmp, get)을 피하고 명확해야 한다
- 보편적인 이름을 사용해야 한다면 꼭 그렇게 해야 하는 이유가 있어야 써야 한다
- 시간이나 바이트와 같은 측정치를 담고 있다면 단위를 포함시켜 보자
- 좁은 범위에서 짧은 이름은 괜찮으나 넓다면 명확하게 하는 것이 더 낫다
- 오해 할 수 없는 이름 짓기
- 경계를 포함하는 한계값 다룰 때는 min/max 가 포함되는 이름이 좋다
- 경계를 포함하는 범위는 first와 last가 이해하기 좋다
- 경계의 시작을 포함하고 끝을 배제할 때는 begin과 end가 이해하기 좋다
- boolean 변수에서 부정 명사보다는 긍정 명사가 이해가 편하다
- get/size와 같은 단어가 포함된 함수는 무거운 기능이어서는 안된다
- 미학적 측면
- lint를 통한 일관성 있는 레이아웃을 사용하라 → 이해하기 더 쉬워진다
- 논리적 영역에 따라 클래스 변수를 여러 개의 그룹으로 나누어라 → 행을 분리하라
- 코드를 논리적 의미에 따라 행을 분리하라
- 주석
- 코드로 빠르게(1~2줄) 유추 가능한 내용이라면 주석에 담지 마라
- 중요한 통찰( 성능, 주의 사항, 결함) 등을 담아라
- 함수 내부의 큰 그림(복잡한 로직) 이 있다면 설명하라
- 주석에서 모호한 대명사(it, this 등)가 여러 가지를 가르킬 수 있다면 사용하지 마라
- 루프와 논리 단순화
- 조건문
- 왼쪽은 검사 대상, 오른쪽은 비교 대상이 이해하기 유용하다
- 간단한 로직을 먼저 처리하거나, 순서 상 긍정문을 먼저 다루어라
- 코드 중복이 발생하지 않는다면 do-while 루프를 사용하지 말아야 한다
- 거대한 표현 쪼개기
- 작은 하위 표현을 담는 변수인 설명 변수를 이용하라
- 복잡한 논리식에는 드모르간의 법칙을 이용해보자
- 코드를 복잡하게 만든다면 쇼트 서킷 평가를 사용하지 말자
- 코드나 조건이 너무 복잡하다면 반대 조건으로 해보는 건 어떨까?
- 변수와 가독성
- 한 번만 사용되거나 명확하다면 불필요한 변수 선언으로 낭비하지 말자
- 변수가 적용되는 범위를 최대한 좁게 만들어야 읽기 좋다
- 클래스 맴버 변수가 아니라면 실제로 사용하기 직전에 변수를 선언하라
- 변수의 값을 최대한 적게 바꾸도록 하면 이해하기 훨씬 쉽다
- 코드 재 작성하기
- 전체 목적에 관계 없는 하위 문제를 다루는 코드를 찾아 별도 함수로 분리하라
- 일반적인 목적을 가진 코드를 많이 만들어라 → 재 사용 가능성이 높다
- 이상적이지 않은 인터페이스를 그냥 받아들여야 할 이유는 없다 → 둘러싸는 함수를 통해 목적을 명확히 표현하자
- 여러 작업을 하는 코드에서 파편화가 되어 있다면 모아서 구조를 수정해 보자
- 함수(문제)를 쉬운 말로 설명해 보자 → 할 수 없다면 아직 이해가 부족한 것이다
- 코드베이스는 작을 수록 좋다!!
- 테스트
- 하나의 완벽한 입력을 하는 테스트보다 작은 테스트를 여러 개 사용하는 방식이 더 효과적이다 → 테스트의 목적을 명확히 하고 케이스 추가가 쉽다
- 100%의 테스트를 목적으로 하기보다 일어날 수 없는 상황을 배제하고 90% 또는 그 이하를 테스트하는 것이 효과적이다