Clean Code Day 5 5장 - 형식 맞추기

Jeeho Park (aquashdw)·2024년 8월 31일

Clean Code

목록 보기
5/10

여전히 회복이 덜되었다. 걸린채로 하루종일 일하는건 확실히 쉽지 않은가보다...그래도 뒤쳐진것 다 따라잡아가는 중.

abstract

Code Format?이었을것 같다. Naming Convention 이야기일 수도 있겠지만 그보다는 들여쓰기, 어디에든 들어갈 수 있는 코드들을 어디에 배치해야 하는지, 괄호의 생략 여부 등에 대한 내용이다. 사실 이 장의 내용은 요즘 IDE들이 자동으로 고쳐주는 경우가 매우 많다. 책에서도 언급한다. 그래도 이왕이면 손에 익혀두는게 나쁘지 않을 듯.

5장 형식 맞추기

프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야 한다. ... 간단한 규칙을 정하고 그 규칙을 착실히 따라야 한다.

잘 훈련된 부대는 제식훈련부터 다르다. 열병식의 모습도 멋있게 보인다. 물론 군인은 슬프다. 잘 운영되는 팀의 코드는 것보기에도 정렬되어 있다. 내용을 읽기 전부터 어디에 무엇이 있는지 눈에 보이는 정도이다.

코드 형식은 의사소통의 일환이다. 의사소통은 전문 개발자의 일차적인 의무다.

오늘 구현한 기능이 다음 버전에서 바뀔 확률은 아주 높다. 그런데 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다.

코드 형식은 가독성에 지대한 영향을 미치고, 이는 앞으로 코드 발전에 큰 영향을 미치는 코드를 사용하는 전문가의 의사소통 능력의 일환이다.

적절한 행 길이를 유지하라

500줄을 넘지 않고 대부분 200줄 정도인 파일로도 커다란 시스템을 구축할 수 있다. 일반적으로 큰 파일보다 작은 파일이 이해하기 쉽다.

  • 신문 기사처럼 작성하라

    • 이름은 간단하고 설명 가능하게
    • 처음에는 고차원적 개념을
    • 아래로 내려갈 수록 의도를 세세하게
  • 개념은 빈 행으로 분리하라

    • 생각 사이에는 빈 행을 넣어 분리한다.
    • package, import, class가 나오는 줄들을 각각 분리해준다.
  • 연관성이 높은 코드는 세로로 가깝게 배치한다.

    • 인스턴스 변수들은 모아서 선언한다.
  • 수직 거리

    • 서로 밀접한 개념은 세로로 가가이 둬야 한다.
    • 타당한 근거가 없다면 밀접한 개념은 한 파일에 속해야 마땅하다.
      • 상속받는 클래스가 접근하게 해주는 protected를 피하자.
    • 변수는 사용하는 위치에 최대한 가까이
    • 인스턴스 변수는 클래스의 처음 부분에, 세로 거리를 두지 않으면서
      • 이는 언어에 따라 다르지만 어쨋든 통상적인 위치에 두도록 하자.
    • 종속 함수(다른 함수가 호출하는 함수)는 가까이 둔다.
    • 개념적 유사성이 높을 수록
      • JUnit에 있는 assertTrue, assertFalse 등은 가까이 배치되어 있다.
  • 세로 순서

    • 호출되는 함수를 호출하는 함수 아래에 둔다.
    • 그러면 글을 읽듯이 자연스럽게 내려가면서 기능을 살펴볼 수 있다.

가로 형식 맞추기

프로그래머는 짧은 행을 선호한다.

  • 이왕이면 한 화면에 들어오면 좋고,
    • 세로 모니터도 많이 쓰는 만큼 그만큼 짧은게 제일 좋을듯
    • PEP에는 제한 길이도 명시되어 있는걸로 안다.
    • 글꼴 축소로 한 화면에 들어간다고 우기지 말자.
  • 가로 공백 밀집도
    • 할당 연산자의 강조를 위해 앞뒤에 여백을 두고,
    • 함수의 이름과 괄호 사이에는 함수를 강조하기 위해 여백을 두지 않는다.
    • 즉 강조되어야 하는 부분이 보이게 공백을 배치한다.
  • 가로로 정렬하려고 하지 말것.
    • 가로로 정렬된 예쁜 코드는 정작 중요한것을 못보게 한다.
  • 들여쓰기
    • 코드가 어느정도 영역에 영향을 미치는지를 나타내는데 들여쓰기는 중요하다.
    • 현재 상황과 무관한 내용을 건너뛰는데도 유용하다.
      • Python은 문법의 일부!
    • 들여쓰기를 무시하고 싶은 간단한 코드가 있다 하더라도 들여쓰기를 써주자.
      • 만약 빈 블록(?!)이 필요하면 다음줄에 ;를 덧붙여 블록이 끝났음을 알려주자.

팀 규칙

은 지키자. 한 소스파일의 형식을 다른곳에서도 발견해야 신뢰감을 보여줄 수 있다.

결론

정말 사소하지만 중요한 내용이 공백의 처리가 아닌가 싶다. 지금도 여러 코드들을 보면 함수, 메서드 이름 뒤에 공백 쓰고 괄호를 넣으면서 +, - 앞뒤에는 공백이 빠지는 코드가 많다. 심지어 이들은 IDE들도 잡아준다! 나름 스타 높은 레포를 클론해도 Pycharm이나 IDEA로 열어보면 노란줄(문법적 오류가 아닌 형식상 비권장) 투성이이다. 그들은 이 노란줄이 눈에 밟히지 않았던 것일까?

그러니 사실 요즘엔 조금만 신경써도 지킬 수 있는게 Code Formatting이다. 특히 코딩을 배우고 있는 입장이라면, IDE가 나에게 주는 신호를 무시하지 말자. 그 신호를 지키면 적당히 이쁜 코드는 얼마든지 만들 수 있고, 그런 코드를 작성해야 내 코드가 좀더 잘 읽히며, 그래야 내가 무슨짓을 한건지를 나중에라도 알아볼 수 있다. 그리고 부끄러워하고, 더 나아가라! 어차피 옛날 코드는 전부 끔찍한 괴물이니까, 과거의 실수를 반복하지만 않으면 된다!

0개의 댓글