[클린 코드] 5장 - 형식 맞추기

 

5장은 팀에서 정할 컨벤션을 만들 때 유용한 주제라고 생각해요.

또한 현재 저는 개인 작업을 하고 있는데, 혼자 하는 작업이더라도 형식을 정해놓는 것이 좋은 것 같아요.

저자가 말하는 원활한 소통을 장려하는 코드 형식에 대해서 이야기 해볼게요.

 

1. 적절한 행 길이를 유지하라

세로 길이부터 살펴보면, 자바에서 파일 크기는 클래스 크기와 밀접해요. 클래스 크기는 이후 다른 챕터에서 다루고 여기서는 파일 크기만 논해요. 

 

JUnit 등의 프로젝트 7개를 봤을 때 평균 파일 크기는 65줄이에요. JUnit에서 가장 긴 파일은 400줄 정도예요. 대다수가 200줄 미만이죠. 반면에 Tomcat과 Ant는 절반 이상이 200줄을 넘고 수천 줄을 넘는 경우도 있어요.

일반적으로 한 파일에서 줄 수가 적은 것이 많은 것보다 이해하기 쉬워요.

 

나의 생각: 현업 코드에서 특정 파일이 2천 줄이 넘는 경우가 있었어요. 구조가 어렵기도 했지만, 너무 많은 코드가 혼재되어있어 이해하기가 더 어려웠던 것 같아요. 그리고 한 파일의 코드가 길다는 것은 검색어로 삼을 만한 키워드가 겹치는 코드들이 많을 가능성이 높다는 뜻도 되기 때문에 원하는 결과물을 검색하기도 어려웠던 것 같아요. 이미 커져버린 파일을 리팩터링 하는 것보다 처음 작성할 때부터 신경 쓰는 것이 코스트가 더 낮다고 생각해요. 개인적으로는 최대 500줄 정도가 괜찮았던 것 같아요.

 

2. 개념은 빈 행으로 분리하라

생각 사이는 빈 행을 넣어 분리해야 해요.

 

나의 생각: 제가 있던 팀은 비교적 자유로웠던 것 같아요. 물론 주석 등 정해진 부분에서 공백 컨벤션은 철저히 지켰지만 그 외의 부분에선 자유도가 있었어요. 다만, 중요했던 것은 일관성이었어요. 한 사람이 작성한 코드에서 공백의 기준이 들쭉날쭉하다는 것은 기준이 없다, 즉 공백에 대한 고려가 없다고 해석될 수 있어요.

 

저의 경우(여기서 공백은 개행/newline)

- import 시 팀 내부에서 만든 모듈과 외부 라이브러리 사이에 공백
- 클래스 사이 공백
- 메서드 사이 공백
- 프로퍼티(필드)와 메서드 사이에 공백

을 기준으로 잡았어요. 이 외에도 프로퍼티 사이에서 특정 프로퍼티가 어떤 역할을 하는 경우(e.g. Dependency Injection, Payload 등) 공백을 넣지만 이 경우는 주석처리를 하고 공백을 만들었어요.

 

3. 세로 밀집도

줄 바꿈이 개념을 분리한다면 세로 밀집도는 연관성을 의미해요. 즉, 서로 밀접한 코드 행은 세로로 가까이 놓아야 해요. 코드가 한눈에 들어오기 때문에 더 읽기 쉬워요. 소스 코드 모듈이 고차원 -> 저차원으로 읽혀요.

 

4. 수직 거리

타당한 근거가 없다면 서로 밀접한 개념은 한 파일에 속해야 마땅해요. 그래서 protected 변수를 피해야 해요. 같은 파일에 속할 정도로 밀접한 두 개념은 세로 거리로 연관성을 표현해요. 여기서 연관성이란 한 개념을 이해하는 데 다른 개념이 중요한 정도예요. 

 

5. 변수 선언

지역 변수는 사용하는 위치에 최대한 가까이 선언해요.

인스턴스 변수는 클래스 맨 처음에 선언해요. 변수 간에 세로로 거리를 두지 않아요. C++에서는 가위 규칙을 적용해서 모든 인스턴스 변수를 클래스 마지막에 선언해요. 하지만 자바에서는 보통 클래스 맨 처음에 인스턴스 변수를 선언해요.

 

나의 생각: 개인적으로도 그렇고 제가 속했던 팀에서도 일반적인 클래스나 구조체를 구현할 때에는 변수 사용 위치와 관계없이 변수는 시작 시점에 모두 선언해주었어요. 하지만 테스트 코드에서 Spy를 만들 때에는 호출 횟수를 확인하는 ~~ Called 변수처럼 메서드에 연관된 값일 경우는 해당 메서드 바로 위에 선언해주었어요. 처음에는 테스트 코드 역시 변수를 위쪽에 몰아서 작업했었는데 테스트의 경우 변경이 쉽게 생길 수 있다는 점, 테스트 스파이의 경우 코드의 전체 구조가 중요한 것이 아니므로 코드가 길어질 경우를 대비한다면 변수가 해당 메서드 바로 위에 있는 것이 읽기 더 편하다는 점 때문에 기준을 변경했어요. 더 정확히 말하면 팀의 컨벤션을 배우고 그 컨벤션이 편하다는 것을 깨달았어요. 지금 생각해보면 Spy 객체 내의 변수라 지역 변수 이므로 이 책의 내용에 부합하는 컨벤션 같아요.

 

절대적으로 저자의 규칙에 따르기보다 읽기 더 편한 상황이 있다면 충분히 대화를 통해 기준을 바꿀 수 있을 것 같아요. 다만 변경이 너무 잦아지면 기존 코드들의 통일성을 해칠 수 있을 것 같아요. 기존 코드의 공백만을 고치는 것 역시 큰 코스트이라고 생각해요.

 

6. 종속 함수

한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치해요. 또한 가능하다면 호출하는 함수를 호출되는 함수보다 먼저 배치해요. 그러면 프로그램이 자연스럽게 읽혀요. 규칙을 일관적으로 적용하면 코드를 읽다가 어떤 함수를 호출할 경우 그 바로 다음에 이 함수가 정의될 거란 사실을 알 수 있어요.

 

7. 개념적 유사성

친화도가 높을수록 코드를 가까이 배치해요. 친화도를 높이는 요인은 여러 가지예요.

- 한 함수가 다른 함수를 호출하는 직접적인 종속
- 변수와 그 변수를 사용하는 함수
- 비슷한 동작을 수행하는 일군의 함수(명명법이 같고 기능 기본이 유사)

서로가 서로를 호출하는 관계는 부차적인 요인이며 명명법과 기본 기능이 유사한 것이 가까이 배치할 우선 기준이 돼요.

 

나의 생각: 호출 관계와 기본 기능 유사의 기준이 부딪히는 상황이 되면, 저는 기본 기능이 유사한 것들을 모아놓고 주석으로 마킹을 할 것 같아요. 애초에 호출 관계일 때 함수를 붙이는 목적 자체가 정의된 것을 바로 찾을 수 있게 함인데, 바로 호출되는 메서드 바로 밑에 함수 정의가 없다면 마킹을 통해 보다 편하게 찾을 수 있을 것 같아요.

 

8. 가로 형식 맞추기

홀러리스(Hollerith)는 가로로 80자를 제한했어요. 하지만 저자는 120자까지는 괜찮다고 생각하고, 그 이후는 주의 부족이라고 판단해요.

연산자 좌 우는 공백을 주어 두 가지 요소가 나뉜다는 사실을 분명히 전달할 수 있지만 함수 이름과 이어지는 괄호의 경우는 공백을 주면 한 개념이 아니라 별개로 보여요.

 

나의 생각: 중요한 건 글자 수가 아니라고 생각해요. 글자수가 80자에 한참 미치지 못하더라도 읽기 힘든 코드가 있고, 그것보다 길어도 읽기 편한 경우도 있다고 생각해요. 특히 iOS의 경우 파라미터가 많은 경우가 있는데 그때에는 개행과 Depth를 통해 읽기 좋게 만드는 게 좋다고 생각해요. 작업을 하며 간과하기 쉬운 게 내가 큰 모니터를 쓸 때인데, 코드를 리뷰하거나 보는 사람이 어떤 환경인지 알 수 없기 때문에 개행은 내가 보는 화면 기준이 아니라 어디에서든 읽히는 기준이 되어야 해요.

 

9. 들여 쓰기 무시하기

때로는 간단한 if 문, 짧은 while 문, 짧은 함수에서 들여쓰기 규칙을 무시하고픈 유혹이 생겨요. 이런 유혹에 빠질 때마다 저자는 항상 원점으로 돌아가 들여 쓰기를 넣어요. 

 

나의 생각: 이것 역시 정말 경우에 따라 다르다고 생각해요. 특히 고차 함수, Rx를 사용할 때에는 오히려 매번 코드 블록을 만들어 들여 쓰기 하는 것이 더 읽기 복잡할 수 있을 것 같아요. 물론 저자의 의도는 코드 줄 수를 줄이려는 노력 vs 가독성에서 가독성이 더 중요하다는 것 같아요. 진리의 케바케

 

10. 팀 컨벤션

결국 가장 중요한 것은 개인의 취향이 아니라 팀 컨벤션이에요. 

 

 

 

 

클린 코드(Clean Code) by Robert.C.Martin