[클린코드] 5장. 형식 맞추기
클린코드(CleanCode)를 읽고 간략하게 정리한 글입니다.
5장. 형식 맞추기
- 프로그래머라면 형식을 깔끔하게 맞춰 코드를 작성해야 한다.
- 코드 형식을 맞추기 위한 간단한 규칙을 정하고 그 규칙을 따라야 한다.
- 팀으로 일한다면 합의해 규칙을 정하고 모두가 그 규칙을 따라야 한다.
1. 형식을 맞추는 목적
- "코드 형식은 중요하다!", 너무 중요해서 무시하기 어렵다.
- 코드 형식은 의사소통의 일환이며, 의사소통은 전문 개발자의 일차적인 의무이다.
- 오랜 시간이 지나 원래 코드의 흔적을 더 이상 찾아보기 어려울 정도로 코드가 바뀌어도 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지 보수 용이성과 확장성에 계속 영향을 미친다.
2. 적절한 행 길이를 유지하라
- 파일의 길이가 500줄을 넘지 않고, 대부분 200줄 정도인 파일로도 프로젝트 구축이 가능하다.
- 일반적으로 큰 파일보다 작은 파일이 이해하기 쉽다.
2-1. 신문 기사처럼 작성하라
- 소스 파일 이름은 간단하면서도 설명이 가능하게 작성한다.
- 이름만 보고도 올바른 모듈을 살펴보고 있는지 아닌지 판단할 정도로 신경 써서 작성한다.
- 소스 파일 첫 부분은 고차원 개념과 알고리즘을 설명한고, 아래로 내려갈수록 세세하게 묘사한다.
- 마지막에는 가장 저차원 함수와 세부 내역이 나온다.
2-2. 개념은 빈 행으로 분리하라
- 대부분의 코드는 왼쪽에서 오른쪽으로, 위에서 아래로 읽힌다.
- 각 행은 수식이나 절을 나타내고, 일력의 행 묶음은 완결된 하나를 표현한다.
- 생각 사이에는 빈 행을 넣어 분리해야 마땅하다.
2-3. 세로 밀집도
- 줄바꿈이 개념을 분리한다면 세로 밀집도는 연관성을 의미한다.
- 서로 밀접한 코드 행은 세로로 가까이 놓여야 한다.
2-4. 수직 거리
- 서로 밀접한 개념은 세로로 가까이 둬야 한다.
- 두 개념이 서로 다른 파일에 속한다면 규칙이 통하지 않지만, 타당한 근거가 없다면 서로 밀접한 개념은 한 파일에 속해야 마땅하고 이것이 protected 변수를 피해야 하는 이유 중 하나이다.
- 같은 파일에 속할 정도로 밀접한 두 개념은 세로 거리로 연관성을 표현한다.
- 변수 선언
- 변수는 사용하는 위치에 최대한 가까이 선언한다.
- 우리가 만드려는 함수는 매우 짧으므로 지역 변수는 각 함수 맨 처음에 선언한다.
private static void readPreferences() {
InputStream is = null;
try {
is = new FileInputStream(getPreferencesFile());
setPreferences(new Properties(getPreferences()));
getPreferences().load(is);
} catch (IOException e) {
try {
if (is != null)
is.close();
} catch (IOException e1) {
}
}
}
- 인스턴스 변수
- 인스터는 변수는 클래스 맨 처음에 선언한다.
- 변수 간에 세로로 거리를 두지 않는다.
- 잘 설계한 클래스는 많은 클래스 메서드가 인스턴스 변수를 사용하기 때문이다.
- Method 중간에 숨겨두면 찾기 어려워진다.
- 종속 함수
- 한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치한다.
- 가능하다면 호출하는 함수를 호출되는 함수보다 먼저 배치한다.
- 규칙이 일관적으로 적용되면 독자는 방금 호출된 함수가 곧 정의될 거라 예측할 수 있다.
- 호출되는 함수를 찾기가 쉬워지며, 그만큼 모듈 전체의 가독성도 높아진다.
- 개념적 유사성
- 친화도가 높을수록 코드를 가까이 배치한다.
- 친화도가 높은 요인은 여러 가지가 있고 아래와 같다.
1. 한 함수가 다른 함수를 호출해 생기는 직접적인 종속성
2. 변수와 그 변수를 사용하는 함수
3. 비슷한 동작을 수행하는 함수
public class Assert {
public static void assertTrue(String message, boolean condition) {
if (!condition)
fail(message);
}
public static void assertTrue(boolean condition) {
assertTrue(null, condition);
}
public static void assertFalse(String message, boolean condition) {
assertTrue(message, !condition);
}
public static void assertFalse(boolean condition) {
assertFalse(null, condition);
}
...
}
2-5. 세로 순서
- 일반적으로 함수 호출 종속성은 아래 방향으로 유지한다.
- 호출되는 함수를 호출하는 함수보다 나중에 배치한다.
- 세세한 사항은 가장 마지막에 표현한다.
3. 가로 형식 맞추기
- 행 길이는 짧은 편이 바람직하다.
- 80자까지는 아니라도 100~120자 정도는 나쁘지 않다.
3-1. 가로 공백과 밀집도
- 가로로는 공백을 사용해 밀접한 개념과 느슨한 개념을 표현한다.
private void measureLine(String line) {
lineCount++;
// 할당 연산자가 강조되어 왼쪽/오른쪽 요소가 나뉨
int lineSize = line.length();
totalChars += lineSize;
// 함수와 인수는 밀접하기에 공백을 넣지 않는다.
// 인수들은 공백으로 분리(별개라는 점을 보여줌)
lineWidthHistogram.addLine(lineSize, lineCount);
recordWidestLine(lineSize);
}
- 위 코드에서 할당 연산자를 강조하려고 앞 뒤에 공백을 주었다.
- 공백을 넣으면 두 가지 주요 요소가 확실히 나뉜다는 사실이 더욱 분명해진다.
- 반면, 함수 이름과 이어지는 괄호 사이에는 공백을 넣지 않았다.
- 함수와 인수는 서로 밀접하기 때문이다.
- 연산자 우선순위를 강조하기 위해서도 공백을 사용한다.
3-2. 가로 정렬
- 나쁜 코드
public FitNessExpediter(Socket s,
FitNesseContext context) throws Exception
{
this.context = context;
socket = s;
input = s.getInputStream();
output = s.getOutputStream();
requestParsingTimeLinit = 10000;
}
- 좋은 코드
public FitNessExpediter(Socket s, FitNesseContext context) throws Exception
{
this.context = context;
socket = s;
input = s.getInputStream();
output = s.getOutputStream();
requestParsingTimeLinit = 10000;
}
- 나쁜 코드의 정렬은 별로 유용하지 않다.
- 코드가 엉뚱한 부분을 강조해 진짜 의도가 가려지기 때문이다.
- 그러므로 좋은 코드와 같이 선언문과 할당문을 별도로 정렬하지 않는 것이 좋다.
- 정렬하지 않으면 오히려 중대한 결함을 찾기 쉬워진다.
- 선언부가 길다면 클래스를 쪼개는 것이 좋다.
3-3. 들여 쓰기
- 소스파일은 윤곽도의 계층이 비슷하다.
- 파일 전체에 적용되는 정보
- 파일 내 개별 클래스에 적용되는 정보
- 클래스 내 각 메서드에 적용되는 정보
- 블록 내 블록에 재귀적으로 적용되는 정보
- 범위(Scope)로 이루어진 계층을 표현하기 위해 우리는 코드를 들여 쓴다.
- 들여 쓰는 정도는 계층에서 코드가 자리 잡은 수준에 비례한다.
- 클래스 정의처럼 파일 수준인 문장은 들여 쓰지 않는다.
- 클래스 내 메서드는 클래스보다 한 수준 들여 쓴다.
- 메서드 코드는 메서드 선언보다 한 수준 들여 쓴다.
- 블록 코드는 블록을 포함하는 코드보다 한 수준 들여 쓴다.
- 들여 쓰기가 없다면 인간이 코드를 읽기란 거의 불가능하다.
- 들여 쓰기한 파일은 구조가 한 눈에 들어온다.
- 들여쓰기 무시하기
- 때로는 간단한 if문, 짧은 while 문, 짧은 함수에서 들여쓰기 규칙을 무시하고픈 유혹이 생긴다.
public class CommentWidget extends TextWidget
{
public static final String REGEXP = "^#[^\r\n]*(?:(?:\r\n)|\n|\r)?";
public CommentWidget(ParentWidget parent, String text){super(parent, text);}
public String render() throws Exception {return "";}
}
- 그러나 이런 코드에도 들여 쓰기를 제대로 표현하는 것이 좋다.
public class CommentWidget extends TextWidget{
public static final String REGEXP = "^#[^\r\n]*(?:(?:\r\n)|\n|\r)?";
public CommentWidget(ParentWidget parent, String text){
super(parent, text);
}
public String render() throws Exception {
return "";
}
}
3-4. 가짜 범위
- 때로는 빈 while 문이나 for 문을 접한다.
- 이런 구조는 가능하면 피하고 피하지 못할 때는 빈 블록을 올바르게 들여 쓰고 괄호로 감싸야한다.
- while 문 끝에 세미클론(;) 하나를 살짝 덧부이지 말고, 새 행에다가 제대로 들여 써서 작성한다.
while (dis.read(buf, 0, readBufferSize) != -1)
;
4. 팀 규칙
- 팀은 한 가지 규칙에 합의해야 하며, 모든 팀원은 그 규칙을 따라야 한다.
- 그래야만 소프트웨어가 일관적인 스타일로 보인다.
- 어디에 괄호를 넣어야 할지, 들여 쓰기는 몇 자로 할지, 클래스와 변수와 메서드 이름은 어떻게 지을지 등을 정하고, IDE 코드 형식기로 설정한 후 사용하는 것이 좋다.
- 좋은 소프트웨어 시스템은 일기 쉬운 문서로 이루어진다는 사실을 항상 기억한다.