적절한 행 길이를 유지하라: 일반적으로 큰 파일보다 작은 파일이 이해하기 쉽다. 길지 않은 줄의 파일로도 커다란 시스템을 구축할 수 있다.
1. 신문 기사처럼 작성하라: 간단하면서도 설명이 가능한 이름을 짓고, 파일 첫부분에는 고차원 개념과 알고리즘을, 아래로 내려갈수록 자세한 의도 표현, 마지막에는 저차원 함수와 세부내역 순으로 정리한다.
  1. 개념은 빈 행으로 분리하라: 생각 사이에는 빈 행을 넣어 분리해야 한다. 빈 행은 새로운 개념을 시작한다는 시각적 단서다.
  2. 세로 밀집도: 연관성을 의미, 서로 밀접한 코드 행은 세로로 가까이 놓아야 한다.
  3. 수직거리: 서로 밀접한 개념은 세로로 가까이 둬야한다.
    1. 변수선언: 변수는 사용하는 위치에 최대한 가까이 선언한다.
    2. 인스턴스 변수: 일반 변수와 다르게, 클래스 맨처음에 선언한다. 변수 간에 세로로 거리를 두지 않는다. 위치에 대한 논쟁이 분분하지만 C++에서는 소위 가위 규칙(모든 인스턴스 변수를 클래스 마지막에 선언)을 적용한다.
    3. 종속함수: 한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치한다. 가능하다면 호출하는 함수를 호출되는 함수보다 먼저 배치.
    4. 개념적 유사성: 친화도가 높을수록 가까이 배치.
      1. 종속성
      2. 변수와 그 변수를 사용하는 함수
      3. 비슷한 동작을 수행하는 일군 함수 -> 종속적인 관계가 없더라도 가까이 배치할 수 있다.
  4. 세로 순서: 함수 호출 종속성은 아래 방향으로 유지. 호출되는 함수를 호출하는 함수보다 나중에 배치.
가로 형식 맞추기: 프로그래머는 명백하게 짧은 행을 선호한다. 80자 제한은 다소 인위적일 수 있으며 100자, 120자에 달해도 나쁘지 않다. 그 이상은 주의부족.
1. 가로 공백도와 밀집도: 가로로는 공백을 사용해 밀접 개념과 느슨한 개념을 표현. Ex) 할당 연산자 사이 공백, 함수 이름과 파라미터 사이 붙임.
2. 가로 정렬: 코드가 엉뚱한 부분을 강조해 진짜 의도를 가릴 수 있음.
3. 들여쓰기: 범위로 이뤄진 계층 표현하기 위해 코드를 들여쓴다. 프로그래밍은 들여쓰기에 매우 의존한다. 들여쓰기가 없다면 인간이 코드를 읽기란 거의 불가능.
  1. 들여쓰기 무시하기: 한 행에 범위를 뭉뚱그린 코드는 피하고 들여쓰기를 무시하지 말자…(응? 소제를 왜 저렇게…)
4. 가짜 범위: 빈 while문이나 for문에 사용. 눈에 띄게 세미콜론을 넣어 줄 것
팀 규칙: 한 가지 규칙에 합의해야한다. 개개인이 따로국밥(이거 번역 전 원본을 보고 싶다.)처럼 맘대로 짜대는 코드는 피해야 한다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

읽기전에 엄청 길게 느껴졌는데, 당연하게 생각되는 내용들이 많아서 그런지 금방 읽어내려갔다.
큰 파일보다 작은 파일이 이해하기 쉽다라는 부분이 있었는데, 팀으로 코드를 짜다보면 400줄이 넘어가기 시작하면 코드를 다른 파일로 분리하거나 리팩토링이 필요하다고 서로들 이야기를 한다. 확실히 한 파일에 모든 본 함수, 도움주는 함수, 컴포넌트들이 쭉 들어있는 것보다 파일 수가 많더라도 잘게 잘라서 분리하는 게 파일 가독성이 훨씬 좋다.
책을 읽으면 읽을 수록 느끼는 거지만, 이 책을 팀 과제 하기전에 다같이 필요한 부분만 단시간에 훅 읽어보고 팀 과제를 시작했다면 어땠을까 생각해본다. 처음 대규모 팀 과제를 했을때, PR하는 법도 모르고, 컨벤션 만들거나 따르는 법도 모르고, 그냥 막 코드를 했을때가 책을 읽으면서 매번 떠오른다… 학교 과제에 형식은 있었지만 c언어를 쓸때까지만 강제되는 형식이었고, 웹 과제에서는 코드 형식이 없고 굉장히 자유로웠다. 그래서 구글 컨벤션등을 보면서 ‘이건 이렇게 비슷하게 하는게 좋지 않겠어?’ 라고 생각은 했지만 아무도 규칙을 지키지 않고 그냥.. 했다…….. 다시금 그 코드를 볼 엄두가 나지 않는다. 하하. 지금은 업무를 하면서 팀이 가진 형식에 맞게 코드를 짜고 정리하는 법을 배우면서 내 개인 프로젝트에는 어떻게 하면 좋겠다 이런 생각을 하지만 역시나 아쉬웠던 때이자 더 잘할 수 있었던 모멘트가 떠오를 수 밖에 없나보다.
‘들여쓰기 무시하기’ 소제는 들여쓰기를 무시하지 말자는 말을 하고 싶었는데 소제를 저렇게 써 놓으니 읽으면서 한 3초 의아했다(ㅎㅎ) 아 그런데 가끔 한줄로 쓰고 싶게 만드는 코드들이 있다. if, else라도 조건이 짧고 실행시키는 스코프가 작다면 그냥 한줄로 쭉… 하지만 ESLint는 참지 않지. 에러를 날려주지… 삼항조건 연산자(는 괜찮자나..?)가 아니면 들여쓰기는 어찌됐든 무시하지 말라.
가짜범위 예시에 나온 걸 C나 C++에서는 가끔 사용한 적이 있었던 것 같은데, 자바스크립트, 타입스크립트를 하면서는 거의 안써본 것 같다. return ;은 써봤지만 조금 맥락이 다르니… 근데 저걸 띄워쓰기나 들여쓰기 하지 않고 그냥 냅다 옆에 세미콜론을 붙이는 경우도 있구나… 아주 가독성 망치기 참 쉬운걸?

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

이번 챕터에서는 처음 들어보거나 어려운 내용 및 단어는 없었다.

오늘 읽은 다른사람의 TIL

글쓰기

노마드코더 이벤트노마드 코더, 강의 1:1 상담 해드려요~️⭐️📚 노마드코더 신간 안내 📚 IT 5분 잡학사전

# interview