> For the complete documentation index, see [llms.txt](https://simian114.gitbook.io/blog/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://simian114.gitbook.io/blog/undefined-1/odds_and_ends/undefined/clean_code/undefined.md).

# Chapter5. 형식 맞추기

## 5.0 형식 맞추기

* 프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야 한다. 코드 형식을 맞추기 위한 간단한 규칙을 정하고 그 규칙을 착실히 따라야 한다. ***필요하다면 규칙을 자동으로 적용하는 도구를 활용한다.***

## 5.1 형식을 맞추는 목적

> 프로그래머의 일차적인 의무는 ***의사소통*** 이다.

* 코드의 형식은 중요하다. 코드 형식은 의사소통의 일환이다. 그리고 이 의사소통은 프로그래머의 일차적인 의무다.
  * **실행되는 코드** 를 만드는게 프로그래머의 일차적인 의무라 여길지도 있다.. 하지만 이제는 아니라는 것을 우리는 안다.
* 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다. 반대로 오늘 코드를 막무가내로 작성하면 미래는 없다....
  * \[깨진 유리창의 법칙]\([https://namu.wiki/w/%EA%B9%A8%EC%A7%84%20%EC%9C%A0%EB%A6%AC%EC%B0%BD%20%EC%9D%B4%EB%A1%A0](https://namu.wiki/w/깨진%20유리창%20이론))
* 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확정성에 계속해서 영향을 미친다. 원래 코드는 사라질지라도 개발자의 ㅅ타일과 규율은 사라지지 않는다. 그렇다면 ***원활한 소통을 장려하는 코드 형식*** 은 무엇일까?

## 5.2 적절한 행 길이를 유지하라

### 5.2.0 적절한 행길이를 유지하라

* 몇 개의 주요한 프로젝트를 확인한 결과 대부분의 평균 파일 크기는 64줄 이었다.  매우 큰 프로젝트 소스 파일 또한 500줄을 넘지 않았고 심지어 대부분이 200줄 미만이었다.
* 이 결과로 우리는 200 줄 미만의 파일로도 대규모 프로젝트를 만들 수 있다는 것을 알았다.
* 반드시 지킬 규칙은 아니지만, 일반적으로 ***작은 파일*** 이 이해하기 쉽다.

### 5.2.1 신문 기사처럼 작성하라

* 좋은 기사를 생각해보자. 독자는 표제를 보고 기사를 읽을지 말지 결정한다. 그리고 첫 문단은 전체 기사 내용을 요약한다. 세세한 사실은 숨기고 커다란 그림을 보여준다. 쭉 읽으면서 내려가면 세세한 사실이 드러난다.
* 소스 파일도 이와 비슷하게 작성한다.
  * 이름은 간단하면서도 설명적으로 짓는다.
  * 이름만 보고도 올바른 모듈을 살펴보고 있는지 아닌지를 판단할 정도로 신경써서 짓는다.
  * 소스 파일 첫 부분은 고차원 개념과 알고리즘을 설명한다.
  * 아래로 내려갈수록 의도를 세세하기 묘사한다.
  * 마지막에는 가장 저차원 함수와 세부 내역이 나온다.

### 5.2.2 개념은 빈 행으로 분리하라

> 생각해보면 빈 행을 사용할 정도로 함수를 길게 만들면 조금 그렇지 않을까?

* 거의 모든 코드는 왼쪽에서 오른쪽으로 그리고 위에서 아래로 읽는다.
* 글을 쓸 때, 우리는 읽기 좋게 하기 위해 `들여 쓰기` 라는 것을 한다. 그리고 이 `들여 쓰기` 의 타이밍은 너무 중요하다. 아마 대부분이 알고 있을 것이다.
* 코드에서도 이 `들여 쓰기`는 너무나 중요하다. (지금 말하는 들여쓰기는 파이썬의 `indent` 같은게 아닌 빈 행을 말함)
* 특히 코드에서는 ***새로운 개념*** 에 대한 내용을 작성할 때 들여쓰기를 한다.
* 그렇게 함으로써 독자는 이전까지 읽던 내용을 정리하고 새로운 내용을 시작할 수 있을 것이다.

### 5.2.3 세로 밀집도

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

### 5.2.4 수직 거리

* 코드를 분석할 때 이 함수, 저 함수 왔다갔다 하는 경험은 누구나 있을 것이다. 그리고 이런 코드는 이해하는데 혼란만 주게된다.
* 서로 밀접한 개념은 세로로 가까이 두어야 한다.
  * 물론 두 개념이 서로 다른 파일에 속한다면 규칙이 통하지 않는다. 하지만 타당한 근거가 없다면 밀접한 개념의 함수는 같은 파일안에 속해야한다.

### 5.2.5 변수 선언

* 변수는 사용하는 위치에 최대한 가까이 선언한다.
  * 42에서는 `C` 스타일을 따라서 인자는 함수의 시작 부분에 선언했지만, 이제는 사용부에 인자를 선언해서 사용하는 습관을 들이도록 하자.

### 5.2.6 인스턴스 변수

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

### 5.2.7 종속 함수

* 한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치한다.
* 또한 가능하다면 호출하는 함수를 호출되는 함수보다 먼저 배치한다.
  * 즉, 고수준의 함수를 위에 저수준의 함수를 아래에 두라는 것.

## 5.3 가로  형식 맞추기

### 5.3.0 가로 형식 맞추기

* 한 행은 가로로 얼마나 길어야 적당할까? 프로젝트 조사 결과 평균은 45줄이었다.
* 일반적으로 옛날에는 80자 제한을 두었지만 현재는 100줄부터 120줄까지로 제한하는 경우가 많다.

### 5.3.1 가로 공백과 밀집도

* 가로로는 공백을  사용해 밀접한 개념과 느슨한 개념을 표현한다. 예를 들면 `func(params)` 처럼 함수 이름과 이어지는 괄호 사이에는 공백을 넣지 않는다. 왜냐하면 함수와 인수는 서로 밀접한 관계가 있기 때문이다. 반대로 `return (a)` 에서는 return 키워드와 a 사이에 공백을 주었다. 이 공백을 이용해 리턴되는 값 자체를 강조하기 위함이다.

### 5.3.2 가로 정렬

* 가로 정렬은 별로 유용하지 못하다.
  * 42스타일에서는 가로 정렬을 필수로 지키게 한다.
* ```cpp
  testStrucureVariable    var;
  int                                        a;
  char                                    b;
  ```
* 가로 정렬이라는건 위와 같은 코드를 말한다.
* 이렇게 하게 되면 중대한 결함을 놓치게 된다고 저자는 말한다. 하지만 난 이게 더 좋은걸..?

## 5.4 팀 규칙

* 모든 프로그래머는 자신이 선호하는 규칙이 있다. 하지만 팀에 속한다면 자신이 선호해야 할 규칙은 바로 ***팀 규칙*** 이다.
* 팀은 ***한 가지 규칙*** 에 합의 해야 한다. 그리고 모든 팀원은 그 규칙을 따라야 한다. 그래야 소프트웨어가 일관적인 스타일을 보이게 된다.