형식을 맞추는 목적
코드를 작성하는 데 있어서 형식을 맞추는 목적은 코드 형식이 의사소통의 방법이며, 오늘 구현한 코드의 가독성이 앞으로 바뀔 코드 품질에 지대한 영향을 끼치기 때문이다.
적절한 행 길이를 유지하라
신문 기사처럼 작성하라
코드는 깔끔한 신문 기사처럼 작성해야 한다.
- 이름은 간단하고 설명이 가능하게
- 아래로 내려갈수록 세세히 묘사 (갈수록 차원이 낮아지도록)
개념은 빈 행으로 분리하라
빈 행은 새로운 개념을 시작한다는 시각적 단서다.
세로 밀집도
서로 밀접한 코드 행은 세로로 가까이 놓여야 한다.
이를 도울 수 있는 방법으로는 추가적인 주석을 작성하지 않는 것이다.
수직 거리
- 서로 밀접한 개념은 한 파일에 속해야 마땅하다.
- 변수는 사용하는 위치에 최대한 가까이 선언하며, 보통 각 함수 맨 처음에 선언한다.
- 루프를 제어하는 변수는 흔히 루프 문 내부에 선언하나, 간혹 블록 상단이나 루프 직전에 변수를 선언하기도 한다.
- 인스턴스 변수는 클래스 맨 처음에 선언한다.
- 호출하는 함수를 호출되는 함수보다 먼저 배치한다.
- 친화도가 높은, 즉 서로 비슷한 기능을 가진 함수들은 가깝게 배치한다.
3번 내용을 이해할 때, while문은 잘 적용할 수 없을 것 같다는 생각이 든다. while문은 조건을 위한 변수가 필연적으로 앞서 작성되는 경우일 것 같아서다.
세로 순서
바로 위에서 작성하였듯, 호출하는 함수를 호출되는 함수보다 먼저 배치한다. 그러면 신문 기사처럼 자연스럽게 위에서 아래로 내려갈 수 있다. 또한, 밑으로 내려갈수록 더 구체적이고 자세한 내용을 담도록 한다. (이는 3장 함수의 내려가기 규칙과 같다.)
가로 형식 맞추기
가로 공백과 밀집도
특정 개념과 개념 사이에 공백이 있다면 서로간의 개념이 분리되어 있다는 것을 강조한다. 반대로, 공백이 없다면 서로간의 개념이 밀접히 연결되어 있다는 것을 강조한다.
totalChars += lineSize; // 할당 연산자 강조
// 함수와 인수 괄호는 공백을 두지 않았다
// 인수와 인수 사이는 공백을 두었다
public static double root1(double a, double b) {...}흥미로웠던 부분은 수식과 관련된 부분이었다.
private static double determinant(double a, double b, double c) {
return b*b - 4*a*c;
}이전까지는 나는 위 코드를 b * b - 4 * a * c;와 같이 표현하였었다. 그런데 위와 같이 표현하면, 진짜 의도한 것 처럼 밀접한 개념 간의 구분을 할 수 있겠다고 생각이 들었다.
하지만 아쉽게도 코드 형식을 자동으로 맞춰주는 도구 대다수가 연산자를 표현할 때 전부 같은 간격을 주어, 내가 줄곧 작성한 방식으로 변경된다고 한다. 그래서 예시 케이스를 잘 못봤던 듯 싶다.
가로 정렬 🙅
저자는 어셈블리 시절, [접근 제어자] [변수 유형] [변수]와 같이 작성하기 위해 길이에 상관없이 전부 공백으로 정렬했다고 한다.
private Socket socket;
private InputStream input;이는 다음 문제점이 있다.
- 코드가 엉뚱한 부분을 강조해 진짜 의도가 가려진다.
- 코드 형식 포맷터가 위 표현을 무시한다.
심할 경우 아래와 같이 피연산자만 더 강조되기도 한다.
this.context = context;
requestParsingTimeLimit = 10000;들여쓰기
들여쓰기를 하는 이유는 범위로 이뤄진 계층을 표현하기 위해서이다.
때로 간단한 if문, 짧은 함수문 등에서 들여쓰기 규칙을 무시하고 싶은 마음이 생길 수도 있겠지만, 항상 원칙과 목적을 생각해 들여쓰기를 제대로 작성하도록 한다.
public CommentWidget(ParentWidget parent, String text) {
super(parent, text);
}
public String render() throws Exception {
return "";
}개인적으로 if문 뒤
continue,return하는 부분 등 (간단한 경우) 에서는 들여쓰기를 하지 않았던 것 같은데, 반성이 되었다.
실제로는 꼼꼼히 들여쓰기를 했어도, IDE에서 표현될 때는 안 된 경우가 있다. 이는 실제로 저장이 그렇게 된 게 아니라 IDE에서 쉽게 표현하기 위해 그렇게 보이는 것이다. 혼동하지 말도록 하자.
가짜 범위 🙅
가능한 빈 for문이나 while문을 작성하지 않도록 한다.
만약 피할 수 없다면 아래와 같이 마지막 행에 세미콜론을 덧붙인다. 눈에 띄기 위함이다.
while (조건)
;이 부분은 접한 적이 없기에 크게 문제되지 않을 듯 하다.
팀 규칙
프로그래머라면 각자 선호하는 규칙이 있다. 하지만 팀에 속한다면 자신이 선호해야 할 규칙은 바로 팀 규칙이다.
팀은 한 규칙에 합의해야 한다. 그리고 모든 팀원은 그 규칙을 따라야 한다. 그래야 소프트웨어가 일관적인 스타일을 보인다.
클린 코드에서도 그렇고, 다른 개발자 분들의 이야기에서도 그렇고 가장 중요한 것은 속한 팀의 컨벤션을 제대로 지키는 것이다.
내가 알고 있던 컨벤션과 다를지라도, 협업을 제대로 할 수 있는 개발자가 되기 위해서는 항상 오픈된 마인드를 가질 수 있도록 하자.
덤으로 많은 사람들이 사용하고 있는 구글 자바 컨벤션에 대해서도 작성해야겠다!
