2012년 2월 22일

이하의 글은 2012년에 쓴 것입니다. 오래된 글인 만큼, 현재의 생각과 전혀 다른 내용도 많이 포함되어 있고, 당시와는 상황이 많이 달라진 점도 있습니다. 또한, 그 당시에 잘못 알려졌던 정보도 포함되어 있을 수 있습니다. 어찌됐든 저는 제 오래된 글이 회자되는 것을 저어합니다. 읽기에 앞서 양해를 부탁드립니다.

도대체 이유를 알 수 없는 코딩 컨벤션도 알고보면 다 나름의 이유가 있는 경우가 많다. 오늘 알게 된 것이 하나 있는데, 여러 대입문이 있을 때 = 연사자를 위아래로 맞추지 않는 컨벤션이 생긴 이유다. 예를 들어 Python의 경우 PEP 8에서 다음과 같이 대입문 세로 정렬을 권하고 있지 않다.

More than one space around an assignment (or other) operator to align it with another.

Yes:

x = 1
y = 2
long_variable = 3

No:

x             = 1
y             = 2
long_variable = 3

PEP 8을 몇년 동안 최대한 지키면서도, 왜 보기도 좋은데 저걸 권장하지 않을까 하고 궁금하게 여겨왔는데, 웹을 돌아다니다가 우연히 어떤 패치를 하나 보고 그 이유를 알게 되었다.

예를 들어, 저 위의 PEP 8에서 예로 든 코드의 경우, 프로그램을 수정하면서 long_variable 변수가 더이상 필요없어지게 되면 어떻게 될까? 그럼 저 셋 중에서 가장 길었던 이름이 사라지므로, 그 다음으로 긴 길이인 한 글자에 모든 정렬을 다시 맞추게 된다. 혹은 long_variable보다 약간이라도 더 긴 변수가 새로 추가되는 경우도 있을 수 있다.

어떤 경우든, 위 아래 정렬을 다시해야 한다. 이쯤 되면 저런식의 정렬을 권하지 않는 이유를 눈치채는 사람들도 있겠지만, 아직 눈치채지 못한 사람이라면 ‘설마 저럴 때마다 위아래 정렬을 다시 맞추는게 번거롭다는 게 이유는 아니겠지’라고 생각할 수도 있다. 물론 고작 그런 이유 때문에 저런 컨벤션이 생긴 것은 아니다. 문제는 패치를 제출할 때 diff가 더러워진다는 점이다.

패치를 리뷰하는데 있어서 변경된 코드의 양은 리뷰하는데 드는 시간을 잡아먹는다. 당연히 모두가 적은 양의 변경으로 원하는 효과를 보는 패치를 선호한다. 즉, 오픈소스 커뮤니티는 대부분 작고 간결한 diff를 원한다. 그런데 저런 식으로 정렬을 해두면 변수 한 두개가 생기고 사라질 때마다 실제 의미는 바뀌지 않았는데도 단순히 위 아래에 다른 변수가 추가되는 바람에 변경된 줄로 표시되는 경우가 발생하게 된다. 이를테면 long_variable 변수가 사라졌다고 하면, 정렬하지 않는 경우:

@@ -1,3 +1,2 @@
 a = 1
 b = 2
-long_variable = 3

이렇게 실제로 사라진 줄만 표시되지만, 정렬을 하는 경우는 다음과 같이 세 줄 모두 변경된 것처럼 표시되게 된다:

@@ -1,3 +1,2 @@
-a             = 1
-b             = 2
-long_variable = 3
+a = 1
+b = 2

이는 비단 오픈소스 커뮤니티가 아니라도, 코드 리뷰를 하는 팀이라면 모두가 번거로울만한 상황이다.

물론 다른 대부분의 코딩 컨벤션과 마찬가지로, 이러한 권고 역시 더 좋은 저작도구를 쓰거나 조직에 맞게 특화시키면 피해갈 수 있다. 이를테면 diff에 옵션을 둬서 공백 문자의 변화는 무시하게 만들 수도 있다. 하지만 그렇다고는 해도 오픈소스 커뮤니티의 경우 그 특성상 특정 도구를 강요할 수 없기 때문에 (가령 이 프로젝트에 참여를 하려면 모두가 Vim이나 Emacs로 편집해야만 한다고 강요한다면 얼마나 황당하겠는가?) 여전히 유효한 권고이기도 하다.

사실 diff가 간결해야 하는 더 중요한 이유는, 사람이 리뷰할 때 힘들기 때문도 있지만, Git이나 Mercurial 같은 버전 관리 시스템에서 머지를 자동으로 해주기 더 수월하기 때문이다. 괜히 쓸데없이 diff를 길게 만들었다가 자동 머지가 깨져서 손으로 머지를 하게 되는 불상사가 생기게 된다.