보고 싶은 코드, 보기 싫은 코드. 코드 컨벤션

사람들마다 성격이 다르고 생각이 다르고 개성이 다르다. 그렇지만 내가 지금까지 수없이 만나왔던 ‘보기 싫은 코드’는 내가 장담하건대 사람의 스타일이 달라서가 아니었다.

한때 KLDP에서 썬의 코딩 스타일과 GNU의 코딩 스타일에 관련된 게시물을 하나 읽게 되었고 코딩 스타일에 대해서 잠깐이나마 고민해 본 적이 있었다. 썬의 코딩 스타일, GNU의 코딩 스타일의 차이 중 중괄호의 표기 방법에 대한 것이었는데 두 스타일의 차이는 이렇다.

// GNU의 스타일
while (var)
{
    if (0 < a)
    {
        continue;
    }
    else
    {
        break;
    }
}

// 썬의 스타일
while (var) {
    if (0 < a) {
        continue;
    } else {
        break;
    }
}

위의 두 코드는 내용이 없는 임의로 작성한 코드이니 코드의 내용보다 중괄호의 형태를 살펴보자.

나는 처음 배울 때부터 썬의 스타일로 배웠고 썬의 스타일로 표기된 책밖엔 보질 못했었다. 그랬기에 GNU의 스타일을 처음 봤을 때 무척이나 신선했다. 썬의 스타일과는 다르게 GNU 스타일은 괄호의 범위나 반대쪽 짝을 알아보기가 훨씬 수월하다.

중괄호가 여러 개 중첩된 코드를 작성하게 될 때마다 중괄호의 범위를 혼동해서 실수할 때가 많았기 때문에 들여쓰기는 그 무엇보다 우선해서 철저하게 하는 편이었다. 코드의 가독성을 높이고 실수를 줄이기 위한 내 나름의 자구책은 철저한 들여쓰기였는데 다른 방법으로 중괄호를 표기하는 방법이 있었다는 것은 미처 생각지 못했었다.

그래서 GNU 스타일이라는 것을 보게 된 이후에 한동한 GNU 스타일로 중괄호를 표기하는 코딩을 한 적도 있었다. 그러나 눈에 익은 게 더 편한 법이라 얼마 지나지 않아 다시 원래의 스타일을 사용했고 들여쓰기를 철저하게 지키려 노력하고 있다.

코드의 가독성을 고민해 보지 않은 사람이라면 절대 저 중괄호의 의미를 모를 것이다. 들여쓰기가 왜 필요한지도 모를 것이다. 이건 정말 간단하면서도 중요한 문제인데도 말이다.

내가 지금까지 접했던 ‘보고 싶은 코드’와 ‘보기 싫은 코드’에는 코딩 스타일(위에 적은 스타일속성과는 전혀 다른)이 크게 작용한 편이다. 들여쓰기가 잘 되어있고 중괄호의 범위를 잘 알 수 있게 만들어두고 연관성 있는 이름으로 변수명, 메소드 명, 클래스 명을 표기해 놓은 코드는 그 코드가 무슨 내용을 담고 있든 간에 한 번쯤 보고 싶게 만드는 코드들이었다. 반면에 들여쓰기가 엉망이고 제멋대로의 변수명에 루프나 메소드의 범위조차 알아보기 힘들게 중괄호를 던져놓은(내팽개쳐 놓은) 코드들은 그 코드가 아무리 위대한(?) 내용을 담고 있어도 나에겐 그저 ‘보기 싫은 코드’ 중의 하나일 뿐이다.

젠장, 아무리 대단한 내용물이 있어도 알아먹을 수 있어야 쳐다보지… 코드를 읽느라고 스트레스받아가며 끙끙대며 시간을 투자할 바에는 대단한 내용물을 포기해 버리는 게 낫다. 사실 들여쓰기 엉망에 변수명 엉망인 코드들은 대단한 내용을 갖고 있을 확률은 희박하다^^ㅋ

코딩 스타일에 대해서는 블로그를 통해서 몇 번인가 썼던 적이 있다. 내가 적었던 글 중에 이런 내용도 있었다.

---

가끔 생각하는 것인데, 정말 누군가를 저주해서 제거해 버리고 싶을 때 이런 방법이 있을 수 있다. 주석하나 없고 이해하기 힘든 변수명이 나열되어있는 긴 소스코드에 추가적으로 어떠한 기능을 더 넣고싶다라는 요구사항과 함께 제거해버리고 싶은 사람에게 넘겨준다. 물론 소스에 대한 어떠한 설명을 해 주어서도 안되며 기왕이면 들여쓰기를 엉망으로 해서 만들어 준다면 효과는 배 이상이 된다. 중간중간 철자가 틀리거나 세미콜론(;)을 빼 두어서 에러를 유발해도 좋다.

class aA{
  int bb;
flat AA
for(S = DD; S > bb; S++){   ...
  ...
         }
     tackle(h);}

대략 이런 형태이면 매우 만족!! 얼마 지나지 않아 좋은 소식이 올 것이다. 그는 이미 머리가 터져서 피를 쏟으며 쓰러져 있을 것이다.

–초급개발자가 본 어의없는 프로젝트 진행 – 싸인펜

---

당시에 위의 내용을 쓰면서 농담처럼 다른 사람을 제거하는 방법이라 적었었는데, 실제로 제거될 수 있다는 사실을 꼭 명심하자. 제거되지 않았더라도 상대방은 엉망의 코드를 보면서 몇 번이고 자살 충동을 느꼈으리라는 것만은 알자.

당신이 들여쓰기, 변수명, 기타 등등 모두가 엉망인 코드를 인수·인계받아서 그 코드를 관리하고 유지보수하는 업무를 맡게 되었다고 생각해보라. 당장이라도 회사를 때려치우고 싶은 심정일 거다. 이해를 최대한 쉽게 만들어 놓은 코드도 이해하려면 어려운 법인데, 엉망인 코드를 건네주는 것은 그냥 그것을 보지 말라는 소리다. 알아보기 힘들게 만들어진 코드들 에러 잡아내고 내용 이해하고 하시는 분들은 정말 존경한다.

나 자신도 초보자이면서 이런 소리 함부로 하면 건방지게 들릴지는 몰라도 들여쓰기 안되어있고 변수명 내키는 대로 쓴 코드를 작성하는 사람은 ‘정말 완전 초보자’이다. 한글로 따지면 띄어쓰기 안 하고 딱딱 붙여서 장문을 쓴다는 소린데 한글을 제대로 배운 사람이라면 그렇게 할까. 정말 ‘정말 완전 한글의 초보자’인 한글을 배우는 외국인들이나 할 수 있는 일이다. 프로그래밍 언어도 똑같다. 언어 제대로 배운 사람이 들여쓰기 안 할까. 들여쓰기 변수명 제대로 안 하는 사람은 정말 초보자다. 코드만 딱 보면 그냥 안다.

코드를 작성할 때 본인을 위해서 작성하지 말고, 다른 사람에게 보여주는 코드라 생각하고 작성하자. 나 편한 대로 하지 말고 다른 사람을 위해서 작성하자. 결국 다른 사람과 동시에 본인을 위한 길이기도 하다. 코드 엉망으로 작성해놓고 에러 안 잡힌다고 울고불고해 봤자 도와줄 수 있는 사람 아무도 없다. 다른 사람이 그 코드를 봤을 때 알아먹을 수 있어야 도움을 주지…

다른 사람에게 코드를 보여줄 때 초보티 내고 싶지 않고 ‘코드 잘 짰다’, ‘가독성이 좋다.’, ‘코드가 눈에 편한데?’ 정도의 평가를 듣고 싶다면 예전에 내가 썼던 ‘코딩 스타일‘ 이라는 글을 참고하길 바란다. 딱 요 정도만 지켜줘도 코드갖고 욕먹는 일은 없을 것이다.

내가 접한 ‘보기 싫은 코드’는 사람의 스타일처럼 사람마다의 개성 때문에 절대 아니었다. 개성을 떠나서 기본적으로 지켜줘야 할 것들을 지켜주지 않았던 코드들이 내가 겪었던 ‘보기 싫은 코드’의 전형적인 모습들이었으니까. 혼자서 작성하는 코드이기에 코딩컨벤션 같은 게 없더라도 그것과의 별개인 기본을 말하는 겁니다.

---

UPDATE 2008.1.20

제가 잘못 알고 있었던 코딩 스타일에 대한 내용이 자세하게 정리된 링크를 추가합니다. GNU 스타일로 알고 있었던 코딩 스타일은 Allman 방식이었고 썬 스타일의 정확한 명칭은 K&R 방식이었군요.

Allman 식 이클립스 Java 코딩 스타일 프로파일

---