5장 형식 맞추기를 읽으면서 내용에 대해 보충하거나, 개인적인 의견으로 반박하거나, 고민해 볼 부분에 대해 적어보려 한다.

형식을 맞추는 목적

형식을 맞추는 것은 너무 당연해서 중요하다는 사실을 잊을 정도다. 형식을 맞추는 것은 코드를 통해 의사소통을 하는 데 있어서 가장 중요한 것이다.

마치 외국어를 사용할 때, 단어만 떠듬 떠듬 말해도 어떻게든 의사소통은 가능하지만, 이해 가능한 수준의 문법으로 말해야 이해가 쉬워지는 것과 비슷하다고 생각하면 된다. (필수는 아니지만 효율성을 위해 지켜야 한다고 생각하면 될 것 같다.)

적절한 행 길이를 유지하라

책에서는 자바를 기준으로 하고 있고, 자바의 경우 파일 단위가 클래스를 기준으로 구분되기 때문에, 파일의 크기는 클래스의 크기에 비례하는 편이다. 클래스의 크기에 관련된 이야기는 6장에서 다루기 때문에 그냥 라인 수를 기준으로 판별했다고 한다. (굳이 클래스의 크기를 비교하자면 멤버 변수, 메서드의 수에 따라 분석할 수 있을 것이다.)

책에서는 JUnit, FitNesse, testNG, Time and Money, JDepend, Ant, Tomcat의 소스 파일을 분석하여 파일당 길이가 얼마나 되는지를 분석해봤다. 일반적으로 200라인 정도에 최대 500라인 정도라고 한다.

신문 기사처럼 작성하라

신문을 보면 헤드라인부터 시작해서 top-down 방식으로 읽기 좋게 구성된다. 코드의 구성을 이런 식으로, 목적을 알 수 있는 제목이나 큰 함수부터 점점 상세한 구현부를 서술하는 방식으로 작성하라는 것으로 보인다.

개념은 빈 행으로 분리하라

개념별로 빈 행을 두어 관련된 코드끼리 그룹을 지을 수 있게 하자. 우리가 글을 작성할 때 문단 단위로 글을 나누는 것과 같은 맥락이라 생각하면 된다.

세로 밀집도

개념별로 빈 행을 두어 구분하듯, 반대로 관련 있는 코드들은 붙여 작성함으로서 서로 관계가 있음을 나타내자.

수직 거리

각 변수나 함수의 정의가 사용되는 곳으로부터 얼마나 멀리 정의되어있느냐를 표현하는 것이다.

현재 맥락과 관련된 변수, 함수의 선언을 가까운 곳에 둬서 커서를 최소한으로 움직이면서 맥락을 확인할 수 있게 배치하란 뜻이다.

세로 순서

관련 있는 순서부터 글을 쓰도록 한다. (Top-down)

가로 형식 맞추기

자바를 기준으로 하면서 가로 길이를 논하는 것이 매우 이상하게 들린다.

기존 프로젝트들을 분석해 본 결과, 가로 밀집도는 보통 20~60자라고 하는데, 가끔씩 긴 키워드들 때문에 (class에서 상속, 인터페이스 정의 등) 일부 코드 행이 120자가 넘는 경우도 많다.

제발 가로로 길게 쓰지 않았으면 좋겠다. 코드 볼때 커서는 위-아래만으로도 충분하다. if문에 검사 조건이 많으면 책에서 얘기하듯 함수로 추출하던가, 아니면 &&이나 || 기준으로 줄을 나눠 썼으면 좋겠다. 한 줄에 다 쓴다고 이해가 더 잘 되는 것도 아니다.

나는 심지어 아직도 80자를 기준으로 잡고 있다. (가끔 애매한 것은 80자를 넘기는 경우도 있지만, 기본적으로 80자를 넘기지 않으려고 노력한다.)

가로 공백과 밀집도

연산자 사이에 공백을 둬서 무슨 연산이 일어나는지 알기 쉽게 하자.

가로 정렬

정렬하는데 피로도는 높아지고, 그렇다고 딱히 효율적이지도 않다. 오히려 타입과 변수명을 멀리 떨어뜨림으로서 그 관계성이 약해지게 만든다.

들여쓰기

리눅스 커널 코딩 스타일을 예시로 들고 싶다.

들여쓰기의 폭을 4칸, 2칸도 아닌 기본 설정인 8칸으로 할 것을 권장한다. 분명 비효율적인 것은 맞지만, 이로 인해 현재 들여쓰기가 과도하게 일어나고 있는 것은 아닌지 되돌아보게 해준다.

팀 규칙

로마에 오면 로마 법을 따라야 한다. 책에서 설명한 형식이 현재 업무에 사용하는 형식보다 좋아보이더라도 일단은 현재 형식을 따르는 것이 더 중요하다.

제일 처음에 이야기했듯, 코드를 통해 의사소통을 할 때 서로 지정된 규정대로 대화하는 것이 좋다.