[Clean Code] 5장. 형식 맞추기

형식을 맞추는 목적

코드 형식은 의사소통의 일환이다

 

• 구현한 기능은 언제든 바뀔 가능성이 있지만 코드의 가독성은 앞으로의 코드 품질에 많은 영향을 미침

맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다. 원래 코드는 사라질지라도 개발자의 스타일과 규율을 사라지지 않는다.

 

적절한 행 길이를 유지하기

• ‘소스 코드는 얼마나 길어야 적당할까’ 에 대한 의문에 그림 5-1(p. 97)에서는 “500줄을 넘지 않고 대부분 200줄 정도인 파일로도 커다란 시스템을 구축할 수 있다” 고 말함

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

 

신문 기사처럼 작성하기

아주 좋은 신문 기사를 떠올려보라. 독자는 위에서 아래로 기사를 읽는다. 최상단에 기사를 몇 마디로 요약하는 표제가 나온다. 독자는 표제를 보고서 기사를 읽을지 말지 결정한다. 첫 문단은 전체 기사 내용을 요약한다. 세세한 사실은 숨기고 커다란 그림을 보여준다. 쭉 읽으면서 내려가면 세세한 사실이 조금씩 드러난다. 날짜, 이름, 발언, 주장, 기타 세부사항이 나온다.

 

• 이름은 간단하면서 설명이 가능하게 짓기
• 소스 파일 첫 부분은 고차원 개념과 알고리즘을 설명하며, 아래로 내려갈수록 세세하게 묘사하기
• 마지막에는 가장 저차원 함수와 세부 내역 작성하기

 

개념은 빈 행으로 분리하라

일련의 행 묶음은 완결된 생각 하나를 표현한다. 생각 사이는 빈 행을 넣어 분리해야 마땅하다.
빈 행은 새로운 개념을 시작한다는 시각적 단서다.

 

• 패키지 선언부, import 문, 각 함수 사이에 빈 행을 넣어 분리하기
• 빈 행을 넣으면 가독성이 올라갈 뿐 아니라 각각의 묶음을 하나의 개념으로 이해하기 쉬워짐

 

세로 밀집도

• 줄 바꿈이 개념을 분리한다면 세로 밀집도는 연관성을 의미함
• 즉, 서로 밀접한 코드 행은 세로로 가까이 놓여야 한다는 뜻

// 목록 5-3 (p. 100)
public class ReporterConfig {
/** 
	* 리포터 리스너의 클래스 이름
	*/
	private String m_classNmae;

/** 
	* 리포터 리스너의 속성
	*/
	private List<Property> m_properties = newArrayList<Property>();
	public void add Property(Property property) {
		m_properties.add(property);
	}
}

// 목록 5-4
public class ReporterConfig {
	private String m_classNmae;
	private List<Property> m_properties = newArrayList<Property>();

	public void add Property(Property property) {
		m_properties.add(property);
	}
}

→ 딱 봐도 목록 5-4 가 훨씬 읽기 쉬움

→ 목록 5-4를 보면 한 눈에 변수 2개에 메서드가 1개인 클래스라는 것을 알 수 있지만

→ 목록 5-3은 코드를 파악하는데 시간이 더 걸림

 

수직 거리

• 서로 밀접한 개념은 세로로 가까이 두기
• 두 개념이 서로 다른 파일에 있다면 규칙을 적용할 수 없겠지만 특별한 이유가 없는 한 서로 밀접한 개념은 한 파일에 있어야 함

 

• 같은 파일에 속할 정도로 밀접한 두 개념은 세로 거리로 연관성을 표현함

연관성이란 한 개념을 이해하는데 다른 개념이 중요한 정도

• 연관성이 깊은 두 개념이 멀리 떨어져 있으면 독자가 소스 파일과 클래스를 여기저기 뒤지게 됨

 

변수 선언

• 변수는 사용하는 위치에 최대한 가까이 선언하기
• 루프를 제어하는 변수는 주로 루프 문 내부에 선언하기

 

인스턴스 변수

• 클래스 맨 처음에 선언하기
• 변수 간에 세로로 거리를 두지 않음
• 언어에 따라 인스턴스 변수를 선언하는 위치에 대해 의견이 다르지만 ‘잘 알려진 위치에 인스턴스 변수를 모은다’ 는 사실이 중요함

 

종속 함수

• 한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치하기
• 가능하면 호출하는 함수를 호출되는 함수보다 먼저 배치하기

// 목록 5-5 (p. 104)
public class WikipageResponder implements SecureResponder {
	...

	public Response makeResponse(FitNesseContext context, Request request) throws Exception {
		String pageName = getPageNameOrDefault(request, "FrontPage");
		loadPage(pageName, context);
		if (page == null)
			return notFoundResponse(context, request);
		else
			return makePageResponse(context);
	}

	private String getPageNameOrDefault(Request request, String defaultPageName) {
		...
	}

	protected void loadPage()...
	
	private Response notFoundResponse()...

	private SimpleResponse makePageResponse()...
}

→ 처음에 makeResponse() 함수내에서 호출된 getPageNameOrDefault() 함수가 그 다음에 정의되었고, 그 이후에 사용된 loadPage(), notFoundResponse(), makePageResponse() 가 차례로 정의된 것을 확인할 수 있음

→ 프로그램을 자연스럽게 읽을 수 있음

 

• 참고로, 위 코드는 상수를 적절한 수준에 두는 좋은 예제

→ getPageNameOrDefault() 를 호출할 때, 인자로 “FrontPage” 라는 상수를 넘기는데

→ 이것을 getPageNameOrDefault() 함수 내에서 사용하는 방법도 있었지만 그렇게 되면 잘 알려진 상수가 적절하지 않은 저차원 함수에 묻히게 됨

→ 상수를 알아야 마땅한 함수에서 실제로 사용하는 함수로 상수를 넘겨주는 방법이 더 좋음!

 

개념적 유사성

• 개념적인 친화도가 높은 경우 코드를 가까이 배치하기
• 친화도가 높은 요인

1. 한 함수가 다른 함수를 호출해 생기는 직접적인 종속성
2. 변수와 그 변수를 사용하는 함수
3. 비슷한 동작을 수행하는 일군의 함수

public class Assert {
	static public void assertTrue(String message, boolean condition) {
		if(!condition)
			fail(message);
	}

	static public void assertTrue(boolean condition) {
		assertTrue(null, condition);
	}

	static public void assertFalse(String message, boolean condition) {
		assertTrue(message, !condition);
	}

	static pubic void assertFalse(boolean condition) {
		assertFalse(null, condition);
	}
}

→ 명명법이 동일하고 기본 기능이 유사하며 간단함

→ 서로가 서로를 호출하는 관계는 부차적인 요인. 종속적인 관계가 없더라도 가까이 배치할 함수들

 

세로 순서

• 일반적으로 함수 호출 종속성은 아래 방향으로 유지함
• 즉, 호출되는 함수를 호출하는 함수보다 나중에 배치하자는 것

(파스칼, C, C++ 의 경우는 함수를 호출하려면 먼저 정의하거나, 적어도 미리 선언해야하므로 이 설명과 반대됨)

 

• 가장 중요한 개념을 가장 먼저 표현하기
• 이 때 가장 중요한 개념을 표현할 때는 세세한 사항을 최대한 배제하며 세세한 사항은 가장 마지막에 표현하기

(위의 목록 5-5가 좋은 예. 더 좋은 예는 목록 15-5(p. 338), 목록 3-7(p. 62))

 

가로 형식 맞추기

• '한 행은 가로로 얼마나 길어야 적당한가' 에 대한 질문에 그림 5-2(p. 107) 에 따라 “짧은 행이 바람직하다” 라는 결론을 보임

→ 20자에서 60자 사이인 행이 총 행수의 40%에 달하며, 10자 미만이 30% 정도를 나타냄

• 요즘은 모니터가 크기 때문에 글꼴 사이즈를 줄인다면 200자까지도 가능하지만 되도록 120자 정도로 행 길이를 제한하기를 권함

 

가로 공백과 밀집도

• 가로로는 공백을 사용하여 밀접한 개념과 느슨한 개념을 표현

private void measureLine(String line) {
	lineCount++;
	int lineSize = line.length();
	totalChars += lineSize;
	lineWidthHistogram.addLine(lineSize, lineCount);
	recordWidestLine(lineSize);
}

→ 할당 연산자를 강조하기 위해 앞뒤로 공백을 줌 (공백을 넣음으로써 왼쪽 요소와 오른쪽 요소가 분명히 나뉨)

→ 함수 이름과 이어지는 괄호 사이에는 공백을 넣지 않음 (함수와 인수는 서로 밀접하기 때문)

→ 함수를 호출하는 코드에서 괄호 안 인수는 공백으로 분리함 (쉼표를 강조해 인수가 별개라는 것을 보여줌)

→ 공백을 넣으면 한 개념이 아니라 별개로 보임

 

• 연산자 우선순위를 강조하기 위해서도 공백을 사용함

public class Quadratic {
	public static double root1(double a, double b, double c) {
		double determinant = determianat(a, b, c);
		return (-b + Math.sqrt(determinant)) / (2*a);
	}

	public static double root2(double a, double b, double c) {
		double determinant = determianat(a, b, c);
		return (-b - Math.sqrt(determinant)) / (2*a);
	}

	private static double determinant(double a, double b, double c) {
		return b*b - 4*a*c;
	}
}

→ 수식을 읽기 편함

→ 승수 사이에는 공백이 없음 (곱셈은 우선순위가 가장 높기 때문)

→ 항 사이에는 공백이 들어감 (덧셈과 뺄셈은 우선순위가 곱셈보다 낮음)

 

💡승수
어떤 수에 다른 수를 나누거나 어떤 식에 다른 식을 곱할 때, 그 나중의 수나 식을 의미함
반대되는 말로 곱해지는 수, 피승수가 있음
예로. (3x+5) x (x-2) 의 식에서 승수는 (x-2) 이며 피승수는 (3x+5) 임

 

참고. 승수(multiplier / multiplicator) | 과학문화포털 사이언스올

 

가로 정렬

private		Socket			socket;
private 	InputStream		input;
private		OutputStream		output;
...
protected	long			requestParsingTimeLimit;
...

public FitNesseExpediter(Socket			 s,
						 FitNesseContext context) throws Exception
{
	this.context =		  context;
	socket =		  s;
	...
	requestParsingTimeLimit = 10000;
}

→ 이와 같이 정렬하는 것은 코드가 엉뚱한 부분을 강조해 진짜 의도를 알기 어려움

 

• 정렬이 필요할 정도로 목록이 길다면 문제는 목록 길이지 정렬 부족이 아님

→ 선언부가 길다면 클래스를 쪼개댜 한다는 의미

 

들여쓰기

• 범위로 이루어진 계층을 표현하기 위해 코드를 들여씀
• 들여쓰는 정도는 계층에서 코드가 자리잡은 수준에 비례함

 

• 들여쓰기를 통해 코드가 속하는 범위를 시각적으로 표현함

 

들여쓰기 무시하기

• 간단한 if 문, 짧은 while 문, 짧은 함수에서 들여쓰기를 무시하고픈 유혹이 생길 수 있지만 들여쓰기를 지켜 범위를 제대로 표현하고자 함

나도 간혹 이런 유혹을 느끼고 실제로 이렇게 쓰는 경우가 있는데 대부분의 경우 한 줄로 표현하는 것을 좋아하는 편은 아니지만 가끔씩 이런 짧은 스타일이 코드를 깔끔하게 보이는 경우도 있다고 생각한다. 

 

가짜 범위

• 빈 while 문이나 for문을 사용해야 한다면 빈 블록을 올바로 들여쓰고 괄호를 감싸주기
• 적어도 세미콜론은 새 행에 제대로 들여써서 넣어주기

while (dis.read(buf, 0, readBufferSize) != -1)
;

 

팀 규칙

• 본인이 팀에 속한다면 팀 규칙을 따라야 함
• 팀은 한 가지 규칙에 합의해야 하며 모든 팀원은 그 규칙을 따라야 함

 

 

개인적으로 공감이 많이 가는 챕터였다. 파일의 길이에 대한 부분에서는 아직 부족하지만 그 외의 내용에 대해 대부분 공감되었다. 이런것을 따지면서 작성했던 건 아니지만 보기 좋은 코드를 작성하다 보면 자연스레 이러한 스타일을 적용하게 되는 것 같다. 학부 프로젝트를 진행할 때 다른 팀원들의 코드 스타일이 안맞으면 짜증이 많이 났었는데 이런 것들을 정해야 한다는 사실을 알고 있었다면 보다 수월하게 진행할 수 있지 않았을까 하는 생각이 들었다. 또한 정말 잘 맞았던 친구와 어떤 것이 그렇게 좋았나 싶었는데 이제와보니 이런 형식을 맞추는 부분에서 서로 말하지 않아도 서로 너무 잘 알고 있었고 그래서, 굳이 이렇게 저렇게 따지지 않아도 일관된 형식을 유지할 수 있어서 였던 것 같다.