Chapter5. 형식 맞추기
Last updated
Was this helpful?
Last updated
Was this helpful?
프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야 한다. 코드 형식을 맞추기 위한 간단한 규칙을 정하고 그 규칙을 착실히 따라야 한다. 필요하다면 규칙을 자동으로 적용하는 도구를 활용한다.
프로그래머의 일차적인 의무는 의사소통 이다.
코드의 형식은 중요하다. 코드 형식은 의사소통의 일환이다. 그리고 이 의사소통은 프로그래머의 일차적인 의무다.
실행되는 코드 를 만드는게 프로그래머의 일차적인 의무라 여길지도 있다.. 하지만 이제는 아니라는 것을 우리는 안다.
오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다. 반대로 오늘 코드를 막무가내로 작성하면 미래는 없다....
[깨진 유리창의 법칙]()
맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확정성에 계속해서 영향을 미친다. 원래 코드는 사라질지라도 개발자의 ㅅ타일과 규율은 사라지지 않는다. 그렇다면 원활한 소통을 장려하는 코드 형식 은 무엇일까?
몇 개의 주요한 프로젝트를 확인한 결과 대부분의 평균 파일 크기는 64줄 이었다. 매우 큰 프로젝트 소스 파일 또한 500줄을 넘지 않았고 심지어 대부분이 200줄 미만이었다.
이 결과로 우리는 200 줄 미만의 파일로도 대규모 프로젝트를 만들 수 있다는 것을 알았다.
반드시 지킬 규칙은 아니지만, 일반적으로 작은 파일 이 이해하기 쉽다.
좋은 기사를 생각해보자. 독자는 표제를 보고 기사를 읽을지 말지 결정한다. 그리고 첫 문단은 전체 기사 내용을 요약한다. 세세한 사실은 숨기고 커다란 그림을 보여준다. 쭉 읽으면서 내려가면 세세한 사실이 드러난다.
소스 파일도 이와 비슷하게 작성한다.
이름은 간단하면서도 설명적으로 짓는다.
이름만 보고도 올바른 모듈을 살펴보고 있는지 아닌지를 판단할 정도로 신경써서 짓는다.
소스 파일 첫 부분은 고차원 개념과 알고리즘을 설명한다.
아래로 내려갈수록 의도를 세세하기 묘사한다.
마지막에는 가장 저차원 함수와 세부 내역이 나온다.
생각해보면 빈 행을 사용할 정도로 함수를 길게 만들면 조금 그렇지 않을까?
거의 모든 코드는 왼쪽에서 오른쪽으로 그리고 위에서 아래로 읽는다.
글을 쓸 때, 우리는 읽기 좋게 하기 위해 들여 쓰기 라는 것을 한다. 그리고 이 들여 쓰기 의 타이밍은 너무 중요하다. 아마 대부분이 알고 있을 것이다.
코드에서도 이 들여 쓰기는 너무나 중요하다. (지금 말하는 들여쓰기는 파이썬의 indent 같은게 아닌 빈 행을 말함)
특히 코드에서는 새로운 개념 에 대한 내용을 작성할 때 들여쓰기를 한다.
그렇게 함으로써 독자는 이전까지 읽던 내용을 정리하고 새로운 내용을 시작할 수 있을 것이다.
세로 여백이 개념을 분리한다면 세로 밀집도는 연관성 을 의미한다.
즉, 서로 밀접한 코드행은 세로로 가까이 놓여야 한다는 뜻.
코드를 분석할 때 이 함수, 저 함수 왔다갔다 하는 경험은 누구나 있을 것이다. 그리고 이런 코드는 이해하는데 혼란만 주게된다.
서로 밀접한 개념은 세로로 가까이 두어야 한다.
물론 두 개념이 서로 다른 파일에 속한다면 규칙이 통하지 않는다. 하지만 타당한 근거가 없다면 밀접한 개념의 함수는 같은 파일안에 속해야한다.
변수는 사용하는 위치에 최대한 가까이 선언한다.
42에서는 C 스타일을 따라서 인자는 함수의 시작 부분에 선언했지만, 이제는 사용부에 인자를 선언해서 사용하는 습관을 들이도록 하자.
인스턴스 변수는 클래스 맨 처음에 선언한다.
한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치한다.
또한 가능하다면 호출하는 함수를 호출되는 함수보다 먼저 배치한다.
즉, 고수준의 함수를 위에 저수준의 함수를 아래에 두라는 것.
한 행은 가로로 얼마나 길어야 적당할까? 프로젝트 조사 결과 평균은 45줄이었다.
일반적으로 옛날에는 80자 제한을 두었지만 현재는 100줄부터 120줄까지로 제한하는 경우가 많다.
가로로는 공백을 사용해 밀접한 개념과 느슨한 개념을 표현한다. 예를 들면 func(params) 처럼 함수 이름과 이어지는 괄호 사이에는 공백을 넣지 않는다. 왜냐하면 함수와 인수는 서로 밀접한 관계가 있기 때문이다. 반대로 return (a) 에서는 return 키워드와 a 사이에 공백을 주었다. 이 공백을 이용해 리턴되는 값 자체를 강조하기 위함이다.
가로 정렬은 별로 유용하지 못하다.
42스타일에서는 가로 정렬을 필수로 지키게 한다.
가로 정렬이라는건 위와 같은 코드를 말한다.
이렇게 하게 되면 중대한 결함을 놓치게 된다고 저자는 말한다. 하지만 난 이게 더 좋은걸..?
모든 프로그래머는 자신이 선호하는 규칙이 있다. 하지만 팀에 속한다면 자신이 선호해야 할 규칙은 바로 팀 규칙 이다.
팀은 한 가지 규칙 에 합의 해야 한다. 그리고 모든 팀원은 그 규칙을 따라야 한다. 그래야 소프트웨어가 일관적인 스타일을 보이게 된다.