코드뷰티파이어(indent) 사용에 대하여

indent라는 C 소스의 들여쓰기, 띄어쓰기 괄호 위치 등을 정리해주는 프로그램은 의외로 오래된 프로그램 중의 하나이다.

1988년의 오래된 이메일
http://www.pell.portland.or.us/~orc/Code/bsd/bsd-current/indent/
를 보면, 원작은 David Willcox가 일리노이 대학교에서 어떤 프로젝트로 인해 필요해서 만들었고, 그 이후 여기 저기 떠돌다가 4.2 BSD에 처음 들어왔다고 한다.

그러나, linux에는 그 소스의 최신(?) 수정본이 들어 있다. 최신이래봐야 2002년 버전인데, 지금쯤 C++이 적절히 반영된 최신버전이 들어옴직한데, 뭘 고민하는지 그간 업데이트가 없다.

indent는 여러 옵션을 가지고(실로 엄청난 옵션이다.) 수행되는데 이 옵션들은 $HOME/.indent.pro 라는 파일에 미리 정의해 놓을 수 있다. 따라서 같은 개발팀이라면 이 파일을 공유하고, 코드들이 코드 저장소(repository)에 반영(commit)되기 전에, 한 번씩 수행하도록하면, 많은 사람들이 동일한 들여쓰기를 사용하게 되어 코드 가독성이 높어지게 된다.

이 시점에서 짚고 넘어 가야할 일이 있다. 코드 가독성을 말할 때, 항상 자신만의 코딩스타일이 가독성이 높으리라는 생각이다. 그러나, 코드 가독성은 많이 보아온 스타일에 대해 가독성이 높을 뿐, 그것이 항상 자신의 코드이기 때문만은 아니다. 오히려 전문성을 발휘한다면, 모든 형태의 들여쓰기에 대해 코드 흐름을 놓치지 않을 수 있는 다양한 경험이 있어야할 것 아닌가.

또 다른 한가지는 들여쓰기같은 사소한 문제로 인해 코드리뷰의 지적 대상을 삼지 말자는 것이다. 이 말은 너무 많이 자신의 습관을 반영했기 때문에 들여쓰기 지적을 하지 말라는 것이 아니라, 그런 정도는 indent 같은 코드 화장품을 좀 도입하자는 것이다. 그리고, 수시로 indent를 돌리는 습관을 기르는 것이 팀을 위해서 좋은 것이다.

indent의 한가지 문제라면, 이미 성숙해 있는 코드에 들여쓰기를 흩어놓는다면, 그것은 코드의 변화상을 추적하기 어려워지는 단점이 있다. 코드의 변화상을 추적하는 것(annotate)은 한 줄 단위로 누가 어떤 리비전에서 작성하였는지를 보고자하는 것인데, indent 라는 놈은 모든 행에 대해 뒤집어 놓기 때문에, 정작 필요한 경우 곤란한 상황에 직면할 수 도 있는 것이다.

따라서, 소스 코드 초기에 진압하지 않으면, indent의 유용성은 단점을 안고 가게 된다. 만약 코드 변화를 추적하는 일도 하지 않았던 팀이라면 중간에 사용해도 크게 어려움이 없다 할 수 있다.

인간이란 규칙을 세우기는 하여도 항상 실수가 있기 마련이고, 그것을 지적하는 것 또한 귀찮은 일이 된다. 문제는 팀 구성원의 개발하는 습관이다. 이 문제는 다음 글에서 다룰일이 있을지 모르겠다.