대범하게

[클린코드] 11~13일차의 1/2 - 원활한 소통을 장려하는 코드 형식 본문

알아두면쓸데있는신기한잡학사전/독서일지

[클린코드] 11~13일차의 1/2 - 원활한 소통을 장려하는 코드 형식

대범하게 2023. 11. 4. 01:31
반응형

[클린코드] 11일차/12일차/13일차의 1/2 - 원활한 소통을 장려하는 코드 형식

클린코드 11일차 (p. 95~102(5장) )

클린코드 12일차 (p. 103~110(5장) )

클린코드 14일차 (p.111~116(5장) / 117~122(6장) )

5 형식 맞추기

형식을 맞추는 목적

- 코드 형식은 너무나도 중요하므로 융통성 없이 맹목적으로 따르면 안 된다.

- 즉, 코드 형식 == 의사소통의 일환 

 

- '돌아가는 코드'가 중요한게 아니다. 시간이 지날 수록 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다. 

- 원래 코드는 사라질지라도 개발자의 스타일과 규율은 사라지지 않는다.

 

목으로 돌아가는 비둘기 같은 코드를 짜놓으면 다음 코드들은 다 목으로 돌아갈 것이다...

그렇다면 원활한 소통을 장려하는 코드 형식은 무엇일까 ?

적절한 행 길이를 유지하라.

- 일반적으로 큰 파일보다 작은 파일이 이해하기 쉽다.

 

1) 신문 기차처럼 작성하라.

- 소스파일도 신문 기사와 비슷하게 작성한다.

- 이름은 간단하면서도 설명이 가능하게 짓는다. 일름만 보고도 올바른 모듈을 살펴보고 있는지 아닌지를 판단할 정도로 ..!

 

2) 개념은 빈 행으로 분리하라.

- 너무도 간단한 규칙이지만 코드의 세로 레이아웃에 심오한 영향을 미친다.

- 어떤 말이냐면 빈 행을 빼버리면 아래와 같은 코드가 탄생한다. -> 가독성 바닥을 향해 ..

 

3) 세로 밀집도

- 줄바꿈이 개념을 분리한다면 세로 밀집도는 연관성을 의미한다.

- 즉, 서로 밀접한 코드 행은 세로로 가까이 놓여야한다.!

 

4) 수직 거리

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

- 물론 두 개념이 서로 다른 파일에 속한다면 규칙이 통하지 않는다.

 

변수 선언

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

예를 들자면,

- 1. 우리가 만든 함수는 매우 짧으므로 지역 변수는 각 함수 맨 처음에 선언

- 2. 루프를 제어하는 변수는 흔히 루프 문 내부에 선언.

- 3. 드물지만 다소 긴 함수에서 블록 상단이나 루프 직전에 변수를 선언하는 사례도 있다.


인스턴스 변수

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

- 인스턴스 변수를 중간쯤에 선언해놓으면 십중팔구 독자는 코드를 읽다가 우연히 발견한다.

 

종속 함수

- 한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치한다.

- 또한, 호출하는 함수를 호출되는 함수보다 먼저 배치한다.

 

개념적 유사성

- 개념적인 친화도가 높을수록 코드를 가까이 배치한다.

예를 들면,

1) 한 함수가 다른 함수를 호출해 생기는 직접적인 종속성

2) 변수와 그 변수를 사용하는 함수

3) 비슷한 동작을 수행하는 일군의 함수

 

가로 형식 맞추기

1) 가로 공백과 밀집도

- 개인적으로는 120자 정도로 행 길이를 제한한다.

- 불행히도, 코드 형식을 자동으로 맞춰주는 도구는 대다수가 연산자 우선순위를 고려하지 못한다.

 

2) 가로 정렬

- 가로 정렬은 별로 유용하지 못하다.

- 코드의 선언부가 길다면 클래스를 쪼개야 한다는 의미이다.

 

3) 들여쓰기

- 범위(scope)로 이뤄진 계층을 표현하기 위해 우리는 코드를 들여쓴다.

- 프로그래머는 들여쓰기 체계에 크게 의존한다.

- 들여쓰기가 없다면 인간이 코드를 읽기란 거의 불가능하리라.

 

들여쓰기 무시하기

- 들여쓰기 규칙을 무시하고픈 유혹이 생기지만, 항상 원점으로 돌아가서 들여쓰기를 넣자.

우측이 들여쓰기를 잘한 코드이다. 훨씬 가독성이 좋다.

 

팀 규칙

- 프로그래머라면 각자 선호하는 규칙이 있지만, 팀에 속한다면 자신이 선호해야 할 규칙은 바로 팀 규칙이다.

- 개개인이 따로국밥처럼 맘대로 짜대는 코드는 피해야 한다.

좋은 소프트웨어 시스템은 읽기 쉬운 문서로 이뤄진다는 사실을 기억하기 바란다. 
스타일은 일관적이고 매끄러워야 하며,
한 소스 파일에서 봤던 형식이 다른 소스 파일에도 쓰이라는 신뢰감을 독자에게 줘야 한다. 
Comments