1.2정돈된 코드 유지하기

저자에 따르면, 코드의 레이아웃에 대한 논쟁이 증가할수록 의미 없는 논쟁으로 빠지게 될 확률이 100%에 가까워진다.

보이는 것은 강력하다

좋은 코드 레이아웃이란 보기에 예쁜 것이 아니라, 명백하며 일관성이 있는 것이다. 오히려 레이아웃은 거의 눈에 들어오지 않는다.

레이아웃을 일관적으로 유지하고, 명명에도 신경을 써야한다.

의사소통

두 명의 관객을 위해 코딩을 하라.

1. 컴파일러(또는 언어 런타임): 오래된 코드 찌꺼기도 읽기를 마다하지 않으며, 자신이 아는 방식으로 실행 가능한 프로그램으로 바꾼다. 즉, 코드 읽기가 아니라 단순 변환 운동을 수행한다.
2. 동료 프로그래머(자기 자신이 될 수도 있다)

보기에는 예뻐도 의도를 파악하기 어려운 코드도 있는데, 대표적으로 주석 박스이다.

javascript
/********
* 정말 쓸데 없는  *
* 아스키 아트이다 *
******** /

이런 주석은 약간이라도 고치려면 *들의 열을 맞추기 위해 노력해야 한다.

레이아웃-절

깔끔하게 글을 쓰고 싶다면, 먼저 생각을 깔끔하게 정리하라.

— 요한 폰 괴테

글을 쓰듯이 코드를 작성하라. 즉, 코드를 장, 문단, 문장 단위로 잘라라. 비슷한 것끼리 묶고 다른 것은 나누라.

또, 코드 연관성과 관련된 순서는 중요하다. 코드 읽을 사람을 고려해, 가장 중요한 정보는 맨 앞에 놓는다. 클래스 정의 최상단에 읽는 사람이 관심있어하는 것을 놓는다. 즉, public을 private보다 먼저 적는다.

짧은 코드로 작성하라. 한 함수 안에 다섯 문단으로 작성하는 대신 잘 명명된 다섯 함수로 나누라.

팀의 동료들과 동일한 레이아웃 규칙으로 코드를 작성한다. 스스로 생각하기에 더 예쁜 방식을 사용하지 않는다. 프로젝트에 일관성이 없다면 표준 코딩 스타일 가이드를 만들고 적용한다. 물론, 상호 합의하에 말이다.

팀 전체의 IDE와 소스 코드 편집기가 같은 환경으로 설정되어 있는지 확인한다. 탭 사이즈를 확인하고, 괄호와 주석 형태, 줄의 종료 옵션을 통일한다.

명명

불필요한 반복을 피한다

아래의 경우를 보자:

javascript
class WidgetList {
  public numberOfWidgets(){
    // ...
  }
}

widget의 리스트인데 굳이 이 단어를 반복할 필요가 없다. size()로 명명할 수 있다.

명확하게 하라

간결함보다 명확함이 우선이다.

타이핑하는 경우보다 변수 이름을 읽는 경우가 더 많으므로, 이름을 불필요하게 짧게 줄이지 않는다. 물론 루프문의 카운터 변수 같은 경우는 컨벤션에 맞게 줄이는게 낫다.

스스로 가다듬기

코드를 정리 정돈하는 경우 기능 변경과 모양 변경을 동시에 진행하지 않는다. 이 둘은 별도의 단계로 소스 관리 시스템에 커밋한다. 레이아웃 변경이 기능면의 실수를 숨길 수도 있다.

---

🥸 생각해보기

1. 회사의 코딩 표준에 맞추기 위하여 레이아웃을 바꿔야 하는가? 아니면 원작자의 스타일을 그냥 두는게 나은가? 그렇다면 이유는?

독립적으로 개발하다가 회사에서 같이 쓰는 경우를 상정한 질문인것 같은데, 개인적으론 코딩 표준에 맞춰야한다고 생각한다. 물론 두명이나 세명 정도 작은 집단이라면 원작자의 의도를 따를 수 있겠지만, 회사의 코딩 표준이라는 것은 회사에서 나름대로의 토론을 통해 정립해서 여러번 시행착오를 통해 고친 형태일 것인데, 협업을 위해선 어느 정도 독특한 스타일의 희생이라는 것은 필수적이라고 생각한다.

2. 코드를 리포매팅해주는 도구는 중요한가? 도구는 당신이 사용하는 언어에 얼마나 의존적인가?

ESLint, Prettier가 해당될텐데, 상당히 중요하다. 가독성을 위해서 띄어쓰기나 "" 또는 '' 사용의 일관성을 한번에 맞춰주는 도구는 개발에 큰 도움이 된다.

아마 프론트엔드 개발자의 대부분이 이런 도구들을 사용하고 있을 것이다.

3. 코드의 외관과 설계 중 어떤 것이 더 중요한가?

설계가 중요하다고 생각한다. 한줄 한줄 차근차근 읽을 때 외관은 큰 영향을 미치지 않는다고 생각한다. 좋은 설계로 작성된 코드는 차근차근 읽을 때 재미도 있고 이해도 쉽다.

하지만 물론 외관을 무시해도 된다는 것은 아니다. 들쭉날쭉한 들여쓰기나 비전통적인 스타일은 가독성을 크게 해친다.

4. 현재 프로젝트에서 코드의 일관성은 어떠한가? 어떻게 개선할 수 있는가?

회사 프로젝트에서 클래스 문법을 통해서만 API 요청을 하는 식으로 코드를 써왔는데, 잠시 자신이 넣고 싶은 기능을 넣으려던 분이 해당 규칙을 어기고 바로 함수를 작성하고 그걸 호출하는 식의 코드를 쓴 적이 있다.

한두건은 리팩토링으로 해결할 수 있지만, 만약 정식으로 개발팀으로 합류한다고 가정하면 이런 규칙에 대해선 미리 최대한 숙지시키고, 어긋나는게 있다면 코드 리뷰때 말하는게 좋을것 같다.

5. 탭 vs 스페이스? 선택한 이유는? 이것이 중요한가?

개인적으로는 탭과 스페이스를 (나름의 개인적인 규칙과 습관에 따라) 혼용해 사용하고 있고, 실제로는 그렇게까지 중요한 문제처럼 느껴지진 않는다.

다만, 코드 스타일을 자동적으로 편집해주는 Prettier 같은 도구를 써서 깃헙에 올리기 전 수정하지 않으면(저장이나 깃훅을 통해) 어떤 파일은 들여쓰기를 2칸 스페이스로 했고, 어떤 파일은 탭으로 해서 마치 PR에서 변경된 것처럼 보여 실제 diff 확인이 어려워질 수 있다.

따라서 코드를 리포매팅해주는 도구를 사용하고 그 규칙을 통일하는 것이 중요하다고 생각한다.

6. 언어의 레이아웃과 명명 규칙을 따르는 것이 중요한가? 아니면 표준 라이브러리와 차별화한 자기만의 스타일을 사용하는 것이 유용한가?

규칙을 따르는 것이 유리하다고 생각한다. 코드는 사람들에게 읽히기 위해서도 작성되는 것이니만큼 차별화된 스타일은 가독성만 떨어뜨린다.

7. 화려한 구문 강조 코드 편집기를 사용하면 색상이 코드의 구조를 나타내준다는 이유로, 코드의 레이아웃에 대해 신경쓰지 않아도 될까?

그렇지 않다. 구문 강조 코드 편집기는 단지 보조 도구일 뿐이다. 해당 확장이 없는 코드 편집기를 쓰는 동료는 소외될 것이다.