개발자들, 왜 코드 빈 칸 때문에 싸우지?

사람마다 쓰는 툴도 다양하지만 쓰는 습관도 천차만멸이다. 코딩 스타일도 제각각이다. 누구는 우아하게 스페이스키를 네번 누르지만, 누구는 터프하게 탭키 한번으로 끝낸다. 중괄호를 문장 끝에 두기도 하고, 다음 줄에 넣기도 한다. 그리고 이 때문에 싸우기도 한다. 별것 아닌 듯 하지만, 코딩 스타일과 코드 컨벤션(프로그램을 짤때 사용되는 일종의 기준을 의미)은 끝없는 논쟁거리다. 본격적인 싸움터로 들어가보자.

■'탁이냐, 탁탁탁탁이냐' 들여쓰기 논쟁

화이트스페이스에 대한 생각은 각자 다르다. 습관 때문일 수도 있다. 탭키를 쓰느냐 스페이스키를 쓰느냐의 싸움은 지금도 정리되지 않았다. 다수결로 어느 비중이 많다 정도다.

탭과 스페이스를 둘러싼 논쟁은 취향의 차이에서 나온다. 탭키의 설정값이 OS마다 다르므로, 스페이스키만 써야 한다는 의견도 있다.

정답은 없다. 탭을 쓰면 한번에 들여쓰기를 할 수 있어 편리하다. 스페이스키를 쓰면 어떤 에디터를 쓰든 똑같이 보인다. 요즘은 들여쓰기를 할 때 툴 차원에서 탭의 설정값을 조절할 수 있다. 화이트스페이스를 언어별 가이드라인에 따라 자동으로 맞춰주는 기능도 있다.

들여쓰기 이중나선 논쟁인 4자 들여쓰기와 2자 들여쓰기도 있다. 콤마, 따옴표, 중괄호, 띄어쓰기 등등 싸움거리는 많다.

“남의 코드를 볼 때 스타일이 다르면 기분이 나쁘다.”

정답은 없지만, 코드 컨벤션은 민감한 문제다. 깃은 탭과 스페이스를 구분하지 못한다. 떄문에 탭이나 스페이스 중 원칙에서 벗어난 것을 쓰면 빨갛게 표시되는 스크립트를 쓰는 사람도 있다고 한다.

중요한 건 마음이다. 남과 협업한다면, 이왕이면 맞추는 게 서로 편하지 않을까. 오픈소스 프로젝트의 경우 아예 커밋을 받지 못할 수 있으니 코드 컨벤션을 숙지하는 건 필수다.

다 더불어 살기 위해서다. 화이트 스페이스 문제를 함께 일하기 위한 프로토콜로 보는 건 어떨까.

"코드 컨벤션 논쟁? 애플은 한방에 정리된다"

애플처럼 난폭한 독재자를 따른다면 코드 컨벤션 때문에 싸울 일은 별로 없다. 오브젝트C는 애플에서 정한대로 안 따르면 큰일 날 수 있다. 메소드명 마음대로 붙였다간, 디버깅하다 눈물 쏙 뺄 에러를 경험하게 된다. 앱스토어 등록이 안 될 지도 모른다. 스위프트는 코드 컨벤션이 별로 없지만, 그래도 애플의 샘플 코드 보고 익히는 게 속편하다.

애플과 놀고 싶다면, 길들여지자. 애플이 나를 길들인다면, 나는 애플에겐 이 세상에서 오직 하나밖에 없는 존재가 될 거다.

■벗어날 수 없는 80자의 굴레

"좋은 코드란 모름지기 80자를 넘으면 안된다."

누가 딱히 시킨 것도 아닌데 80자를 넘기지 말아야 한다는 강박관념은 개발자들의 DNA 염기서열 속에 깊숙이 자리 잡아 좀처럼 그들을 놓아주지 않는다.

개발자들은 "코드를 길게 짜는 걸 좋아하지 않아서", "습관이 된 건지 모르겠는데 긴 코드가 싫다"고 한다.

가독성을 생각하면 당연히 긴 코드보다 짧은 것이 좋은 줄은 다 알지만 왜 꼭 80자여야 하나?

개발계 현인들은 개발자들의 80자 강박관념을 이렇게 설명하고 있다. "사실 하나도 안 중요하다"고. 명쾌한 답이다. 하지만 "역사와 전통을 자랑하는 이유들이 습관으로 남아 있는 것"이라고 한다.

옛날 옛적 터미널 크기가 ‘80*25’였던 시절. 고정폭 폰트로 80자는 딱 터미널 사이즈에 맞았다. 80자가 넘으면 다음 줄에 나오거나 안 보이거나 둘 중 하나. 그 후로부터 '보기 좋은 코드=80자' 공식이 성립된 것이다.

80자를 넘겼다면? 다음 심리적 마지노선은 130자다. 130자 코드컨벤션은 프린터 용지에서 왔다. 옛날 옛적 쓰던 프린터 용지가 132자였다. 출력해서 봤을 때 보기 좋게 나오려면 120자 혹은 130자를 넘지 말아야 하는 건 당시 굉장히 중요한 거였다.

딴 얘기지만 개발자들은 익숙한 것에 끌린다. 심지어는 한 개발자는 레드햇8을 지난해까지 썼다고 한다. 안드로이드를 빌드해야 하는데, 컴파일이 안 돼서 어쩔 수 없이 눈물을 머금고 바꿨다나.

하여간, 요즘엔 변수 이름을 길게 짓는 경향이 있기 때문에 80자, 130자 형태를 지키기 쉽지 않은 것도 사실이다. 그래도 짧은 코드는 여전히 예쁜 코드의 조건이다.

한 GNU 개발자는 "애플2로 처음 코딩을 시작했을 땐 40칼럼이었다"고 말하며 묘한 웃음을 지어 보였다.

■마음의 평온을 불러오는 '폰트'

짧다고 능사는 아니다. 코드를 나타내는 폰트의 때깔 역시 개발자의 심미안을 자극한다. 우선 여태 말한 한줄 40자, 80자, 130자 기준은 한가지 대전제를 깔고 있다. 어떤 글자든 1자의 너비가 똑같을 것.

“중요하다. 일단 코드라인 폭이 들쭉날쭉하면 싫으니까. 마음이 불편하니까.”

장평이 제각각인 글꼴은 글자수가 같은 라인도 들쭉날쭉을 만든다. 글자수 똑같은 코드가 왜 가지런하질 못하니.. 아내에게 설렁탕 못 먹인 김첨지에 빙의돼 보면 I와 W가 화면에서 똑같은 폭을 차지하는 고정폭글꼴을 찾을 수밖에.

한글의 줄과 각을 살린 나눔고딕코딩은 신흥강자. 한글이 대수가 아닐 땐 스테디셀러인 콘솔라스(Consolas)나 픽스드시스(FixedSys)를, 맥에선 모나코(Monaco)를, 리눅스에선 베라산스모노(Vera Sans Mono)를 써보자.

“에어리얼(Arial) 딱 싫다. 알파벳계 굴림체라 해야하나.”

개발자도 사람인데 취향이 같을 리 있겠나. 하고많은 고정폭글꼴 중 코딩할 때 선호하는 폰트를 한두 가지로 정리할 순 없는 노릇이다. 하지만 코딩할 때 제일 안 쓰는 글꼴만큼은 에어리얼 폰트로 어느정도 컨센서스가 이뤄진 모습이다.

■개발툴에 대한 말말말

개발자들이 마다 개발툴에 대한 취향이 제각각이라, 개발툴의 세계는 이런저런 말들도 정말 많다. 개발툴에 대해 개발자들이 하는 얘기를 들여다 보고 있으면 우리나라 개발자 문화의 단면들을 엿볼 수 있다. 취재하면서 접했던 얘기들을 담아봤다.

“우리 회사는 비주얼스튜디오 기본인데, VIM을 깔면 남들이 이직 준비하냐고 한다.”“동료가 내 자리에서 일할 때 당황하지 않도록 접대용 키보드를 준비하는 게 어떨까?”“한때는 나도 VI 화려하게 쓰고 싶었고, 노력도 해봤다. 나이가 들어서 그랬나? 그러다 다 부질없다는 생각이 들었다. 사실 타이핑만 하는 시간은 생각보다 길지 않다.”“유니코드가 아니라 완성형 한글을 쓰는 분이 있다. 한터미널을 쓰기 위해서.”“VI 잘 써보려고 단축키 리스트를 좍 뽑아서 책상 옆에 딱 붙여놨다. 근데 잘 안 본다.”“한때는 화면 3개까지 놓고 컴퓨터도 여러대 놓고 일했다. 그러다보니 일을 너무 많이 하게 되더라.”“튜닝의 끝은 순정이다. 매크로 아무리 만들어봐야 프로젝트 바뀌면 안쓰게 되고, 나중에 쌓이면 로딩하기도 귀찮다. 그냥 몇글자 더 치고 말지.”

3편에 계속...

[연재 순서]

① 뇌섹 개발자로 만들어주는 툴의 세계

② 개발자, 코드 빈 칸으로 왜 싸우지?