가독성 높은 코드를 작성하라-2

해당 포스팅은 톰 롱의 Good Code, Bad Code (P.134~146)를 읽고 정리한 글입니다.

 

일관된 코딩 스타일을 고수하라

잘 읽히는 문장을 쓰기 위해 따라야 할 문체에 관한 지침들도 있다. 코드도 마찬가지다.

 

일관적이지 않은 코딩 스타일은 혼동을 일으킬 수 있다.

예를 들어 클래스 이름은 일반적으로 첫 글자를 대문자로 작성되는 반면 변수 이름은 소문자로 시작한다. 만약 이것을 지키지 않게 된다면 예상치 못한 버그가 발생할 수 있다.

 

스타일 가이드를 채택하고 따라야 한다

일관된 코딩 스타일을 가지게 된다면 가독성이 좋아지고, 팀 간의 오해가 줄어들고 버그가 사라진다.

 

코딩 스타일이 다루는 측면

• 명명법
• 언어의 특정 기능 사용
• 코드 들여쓰기
• 패키지 & 디렉터리 구조화
• 코드 문서화 방법 등.

린터(linter)
스타일 가이드를 따르지 않는 코드를 찾아 알려주는 도구
린터는 일반적으로 아주 간단한 문제만 잡기 때문에 처음부터 좋은 코드를 작성하는 것을 대체할 수는 없다. 하지만 린터는 코드를 개선하기 위한 빠르게 쉬운 방법이다.

---

깊이 중첩된 코드를 피하라

코드의 구조가 가독성에 어떤 영향을 미칠지 고려하는 것은 중요하다.

 

깊이 중첩된 코드는 읽기 어려울 수 있다

코드를 읽고 각 코드 라인의 중첩 수준이 정확히 어느 정도인지 추적하기 쉽지 않다. 이로 인해 코드를 읽을 때, 다른 논리가 실행되는 때를 정확히 이해하기 어렵다. 중첩이 깊어지면 가독성이 떨어지기 때문에 중첩을 최소화하도록 코드를 구성하는 것이 바람직하다. 중첩된 모든 블록에 반환문이 있을 때, 중첩을 피하기 위해 논리를 재배치하는 것이 일반적으로 아주 쉽다.

 

중첩은 너무 많은 일을 한 결과물이다

중첩된 블록에 반환문이 없다면, 그것은 대부분 함수가 너무 많을 일을 하고 있다는 신호이다. 이를 해결하기 위해 더 작은 함수로 분리해야 한다. 분리하면 추상화 계층을 개선하고 중첩을 제거할 수 있어 합리적이다.

---

함수 호출도 가독성이 있어야 한다

가독성을 위해 함수명도 중요하지만 파라미터가 무엇을 위한 것인지 무슨 역할을 하는지 이해하는 것도 중요하다. 

함수 인수가 많다면? 
함수 호출은 인수의 개수가 늘어나면 이해하기 힘들어진다. 함수나 생성자가 많은 수의 매개변수를 가지고 있으면 이것은 보다 근본적인 문제를 나타내는 것일 수 있다. 예를 들어 추상화 계층을 적절하게 정의하지 않았거나 코드가 충분히 모듈화 되지 않았음을 의미할 수 있다.

 

함수 호출 시 각 인수의 값이 무엇을 의미하는지 알려면 함수 정의를 확인해 봐야 한다. 그러나 일일이 찾아보는 것은 상당히 어려운 작업이다. 이를 개선하는 방법은 다음과 같다.

 

명명된 매개변수

명명된 매개변수를 지원하는 언어에서는 이를 활용하는 것이 좋다. JavaScript와 TypeScript에서는 객체 구조 분해를 사용하면 명명된 매개변수와 유사한 효과를 얻을 수 있다. 자바에서는 명명된 매개변수를 지원하지 않는다.

 

함수를 정의할 때 좀 더 서술적인 유형을 사용해야 한다

정수, Boolean 은 상황에 따라 어떤 종류의 값이라도 의미할 수 있기 때문에 그 자체로 서술적이지 않다. 따라서 함수를 작성할 때  클래스나, Enum과 같은 특정 유형을 만들어 그 매개변수들이 나타내는 바를 설명하는 것이다.

 

때로는 해결책이 없을 수 도 있다. 

함수 호출 시 가독성을 높일 특별한 방법이 없을 때가 있다. 인라인 주석을 사용할 수도 있지만, 유지보수 비용이 들고 최신화되지 않으면 오히려 문제가 발생할 수 있어 추천하지 않는다. Setter나 Builder를 사용할 수 있지만, 파라미터 누락 위험이 존재한다.

 

IDE 활용

일부 IDE는 함수의 매개변수 이름을 표시해 주지만, 이에 과도하게 의존하지 않는 것이 좋다. 모든 개발자가 해당 기능을 사용하는 것도 아니며, 모든 상황에서 IDE의 지원을 받을 수 있는 것도 아니다.