[Day 3] 형식 맞추기

가독성과 팀의 규칙을 중요시한 파트 ➡️ 코드의 형식은 유연하게 상황에 맞게 작성하라.

적절한 행 길이를 유지하라

500줄을 넘기지 않고 대부분 200줄 정도인 파일로도 커다란 시스템을 구축할 수 있다.

'200줄 내외로 코드를 작성한다'를 바람직한 규칙으로 삼아라.

신문 기사처럼 작성하라

모듈의 이름만 보고 올바른 모듈인지 아닌지를 판단할 수 있을 정도로 작성하라. 모듈의 이름은 신문 기사의 표제다.

소스 코드의 첫 부분은 높은 추상화 수준으로, 아래로 내려갈수록 낮은 추상화 수준으로 의도를 세세하게 묘사하자.

개념은 빈 행으로 분리하라

빈 행은 새로운 개념을 시작한다는 시각적 단서다.

세로 밀집도

세로 밀집도는 연관성을 의미한다. 여기서 연관성이란 한 개념을 이해하는 데 다른 개념이 중요한 정도이다.

서로 밀접한 개념은 세로로 가까이 둬야 한다.

'project 변수를 피해야 한다.'고 책에선 말한다. ➡️ 서로 밀접한 개념이라면 한 파일에 속해야지 같은 패키지 내의 다른 파일에 속해선 안되기 때문이다.

---

변수 선언

변수는 사용하는 위치에 최대한 가까이 선언한다.

---

인스턴스 변수

인스턴스 변수는 클래스 맨 처음에 선언한다.

---

종속 함수

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

위 개념은 내려가기 규칙[2024.10.23 - [Clean Code] - [Day 2] 함수]과 중복한 내용이라고 생각한다.

 

💡 낮은 추상화 수준의 함수에 상수를 사용하지 말고, 상수를 알아야 하는 함수 ➡️ 실제로 상수를 사용하는 함수로 상수를 넘겨주는 방법이 바람직하다. (가독성이 좋고 수정하기 편하기 때문이다.)

---

개념적 유사성

개념적인 친화도가 높은 코드끼리는 가까이 배치한다. 개념적인 친화도가 높다는 건

1. 한 함수가 다른 함수를 호출하는 종속적 관계
2. 변수와 그 변수를 사용하는 함수
3. 비슷한 동작을 수행하고 명명법이 같은 경우

를 의미한다.

---

가로 형식 맞추기

짧은 행이 바람직하다. 120자 정도로 행 길이를 제한하는 것을 규칙으로 삼아보자.

가로 공백과 밀집도

private static double determinant(double a, double b, double c) {
    return b*b - 4*a*c;
}

나라면 b \* b - 4 \* a \* c;라고 작성했을 것이다. 위 예시가 훨씬 더 가독성이 좋다. 수식을 사용할 때는, 예시처럼 작성하는 연습을 하자.

가로 정렬

가로 정렬은 하지 말자. 정렬이 필요할 정도로 목록이 길다면 문제는 목록 길이지 정렬 부족이 아니다. 이 경우는 클래스를 쪼개야 한다.

들여쓰기

if, else문, while문의 블록안에 한 줄만 들어갈 때,

// 내가 작성하는 방식
if (a == b) list.add(a);

// 앞으로 작성할 방식
if (a == b)
    list.add(a);

다음과 같은 방식으로 코드를 많이 작성했다. 이 경우엔 들여쓰기를 사용해 가독성을 높여보자.

---

팀 규칙

프로그래머라면 각자 선호하는 규칙이 있겠지만, 팀 규칙에 따라야 한다. 코드를 읽는 팀원들이 읽기 쉬운 문서로 코드가 작성해야 하기 때문이다. 한 소스 파일에서 봤던 형식이 다른 소스 파일에도 쓰이리라는 신뢰감을 팀원들에게 줘야 한다.

 

이전 개념들과 중복된 개념들이 몇 가지 나왔다. 그만큼 '필수로 지켜라' 라고 들린다.