북클럽 클린코드 5장. 형식 맞추기

형식을 깔끔하게 맞춰 코드를 짜야 한다.
코드 형식을 맞추기 위한 간단한 규칙을 정하고 그 규칙을 착실히 따라야 한다.
팀으로 일한다면 팀이 합의해 규칙을 정하고 모두가 그 규칙을 따라야 한다.
필요하다면 규칙을 자동으로 적용하는 도구를 활용한다.

형식을 맞추는 목적

• 융통성없이 맹목적으로 따르면 안된다.
• 코드 형식은 의사소통의 일환이다.
• 의사소통은 전문 개발자의 일차적인 의무다.
• 돌아가는 코드가 전문 개발자의 일차적인 의무라 여길지도 모르겠다.
  • 하지만 이 책을 읽으면서 생각이 바뀌었기 바란다.
  • 오늘 구현한 기능이 다음 버전에서 바뀔 확률은 아주 높다.
  • 그런데 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 끼친다.
  • 오랜 시간이 지나 원래 코드의 흔적을 더 이상 찾아보기 어려울 정도로 코드가 바뀌어도 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 끼친다.
  • 원래 코드는 사라질지라도 개발자의 스타일과 규율은 사라지지 않는다.
• 그렇다면 원활한 소통을 장려하는 코드 형식은 무엇일까?

적절한 행 길이를 유지하라

• 500줄을 넘지 않고 대부분 200줄 정도인 파일로도 커다란 시스템을 구축할 수 있다.
• 반드시 지킬 규칙은 아니지만 바람직한 규칙으로 삼으면 좋겠다.

신문 기사처럼 작성하라

• 독자는 위에서 아래로 기사를 읽는다.
• 위에는 고차원, 내려갈수록 세세하게

개념은 빈 행으로 분리하라

• 일련의 행 묶음은 완결된 생각 하나를 표현한다.
• 생각 사이는 빈 행을 넣어 분리한다.

세로 밀집도

• 줄바꿈이 개념을 분리한다면 세로 밀집도는 연관성을 의미한다.
• 서로 밀접한 코드 행은 세로로 가까이 놓여야 한다는 뜻이다.

수직 거리

• 함수 연관 관계와 동작 방식을 이해하려고 이 함수에서 저 함수로 오가며 소스 파일을 위아래로 뒤지는 등 뺑뺑이를 돌았으나 결국은 미로 같은 코드 떄문에 혼란만 가중된 경험이 있는가? 그렇다.
• 함수나 변수가 정의된 코드를 찾으러 상속 관계를 줄줄이 거슬러 올라간 경험이 있는가?
• 이조각 저조각이 어디에 있는지 찾고 기억하느라 시간과 노력을 소모한다.
• 서로 밀접한 개념은 세로로 가까이 둬야 한다.
• 타당한 근거가 없다면 서로 밀접한 개념은 한 파일에 속해야 마땅하다.
• 같은 파일에 속할 정도로 밀접한 두 개념은 세로 거리로 연관성을 표현한다.

변수 선언

• 사용하는 위치에 최대한 가까이 선언한다.
• 지역변수는 각 함수 맨 처음에 선언
• 루프 제어 변수는 루프 문 내부에 선언
• 루프 직전에 변수를 선언하는 경우는 다소 긴 함수인 경우

인스턴스 변수

• 인스턴스 변수는 클래스 맨 처움에 선언한다.
• 변수 간에 세로로 거리를 두지 않는다.

[!NOTE]
잘 설계한 클래스는 많은 클래스 메서드가 인스턴스 변수를 사용하기 때문이다.

• 인스턴스 변수를 선언하는 위치는 아직도 논쟁이 분분하다.
• C++에서는 모든 인스턴스 변수를 클래스 마지막에 선언한다는 소위 가위 규칙(scissors rule)을 적용한다.
• 하지만 자바에서는 보통 클래스 맨 처음에 인스턴스 변수를 선언한다.
• 나로서는 어느 쪽이든 이유가 없다.
• ==잘 알려진 위치에 인스턴스 변수를 모은다는 사실이 중요하다.==
• 변수 선언을 어디서 찾을지 모두가 알고 있어야 한다.

종속 함수

• 한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치한다.
• 호출하는 함수를 호출되는 함수보다 먼저 배치한다.

개념적 유사성

• 어떤 코드는 서로 끌어당긴다.
• 개념적인 친화도가 높기 때문이다.
• 친화도가 높은 요인
  • 호출하는 관계. 직접적인 종속성
  • 변수와 그 변수를 사용하는 함수
  • 비슷한 동작을 수행하는 일군의 함수
    • 명명법이 똑같고 기본 기능이 유사하고 간단하다.
    • 서로가 서로를 호출하는 관계는 부차적인 요인이다.
    • 종속적인 관계가 없더라도 가까이 배치할 함수들이다.

가로 형식 맞추기

• 프로그래머는 명백하게 짧은 행을 선호한다.
• 20자에서 60자 사이가 전체의 40%
• 10자 미만은 30자
• 80자 이후부터는 급격하게 감소
• 100자나 120자도 나쁘지 않다. 하지만 그 이상은 주의 부족이다.

가로 공백과 밀집도

가로 정렬

• 탭 맞춰서 정렬하는거
• 정렬이 필요할 정도로 목록이 길다면 문제는 목록 길이지 정렬 부족이 안다.
• 아래 코드처럼 선언부가 길다면 클래스를 쪼개야 한다는 의미다.

들여쓰기

들여쓰기 무시하기

• 간단한 if문, 짧은 while문, 짧은 함수에서 무시하고픈 유혹이 생긴다.
• 한줄에 범위를 뭉뚱그린 코드를 피한다. 원점으로 돌아가 들여쓰기를 넣어라.

가짜 범위

• 빈 반복문
• 빈 조건문
• 하지마라

팀 규칙

• 팀 규칙이라는 제목은 말 장난이다.
• 프로그래머라면 각자 선호하는 규칙이 있다.
• 하지만 팀에 속한다면 자신이 선호해야 할 규칙은 바로 팀 규칙이다.
• 팀은 한 가지 규칙에 합의해야 한다.
• 그리고 모든 팀원은 그 규칙을 따라야 한다.
• 개개인이 따로국밥처럼 맘대로 짜대는 코드는 피해야 한다.
• 스타일 논의하는데 오랜 시간이 걸리지 않는다.
  • 어디에 괄호를 넣을지
  • 들여쓰기는 몇자리로 할지
  • 클래스와 변수와 메서드 이름은 어떻게 지을지 등을 결정했다.
  • 그리고 IDE 코드 형식기를 설정한 후 사용한다.