코딩 스타일

[목차]

개요

코딩 스타일이라 함은 기본적으로 소스 코드를 작성할 때의 불문율적인 편집 규약에 가깝다.

사실 기계가 이해하기엔 결과적으로 동일하지만, 코드를 작성하는 건 인간이기 때문에 (비단 코드를 짠 본인이 아니라도) 열람 및 유지보수를 용이하게 하기 위해 어느 정도 통일된 스타일의 필요성이 생겨난 것으로 추정된다.

이러한 코딩 스타일은 코드 유지보수에 큰 영향을 끼치며, 좋지 않은 코딩 스타일에 익숙해질 경우 능률이 저하되거나 타인과의 공동작업에서 혼란이 가중될 수 있으니 참고하자.

큰 의미로는 디자인 패턴이 코딩 스타일을 포괄한다.

괄호의 위치

괄호의 위치에 따른 코딩 스타일에는 대표적으로 BSD, K&R, GNU 3개가 있다.

각 코딩 스타일은 서로 장단점이 있으며 ~~당연한 이야기지만 자기가 익숙한 스타일이 다른 코딩스타일보다 더 좋아보인다~~, 다수의 프로그래머가 모였을때 혼란의 원인이 되기도 한다. 코딩 스타일은 부먹찍먹 논쟁과 흡사하다. 서로간의 취향 차이일뿐 완벽한 코딩 스타일이란 존재하지 않으므로 자신이 사용하는 코딩 스타일이 다른 스타일보다 우월하다고 주장하는 우를 범하지 말도록 하자. 단, 해당 언어를 만든 쪽에서 직접 코딩 컨벤션을 지정한 경우에는 그걸 따르는 게 좋다.[* 예를 들어 들여쓰기의 경우 Python은 스페이스 4칸, Go는 8칸짜리 탭.]

대부분의 언어는 대표 코딩 컨벤션을 가지고 있다. 일반적으로 그 언어의 표준을 따르게 되며, 프로젝트별로 코딩 스타일이 정해져 있는 경우도 있다. 따라서 개인 프로젝트가 아닌 이상, 자기가 좋아한다고 해서 마음대로 코딩 스타일을 변경하기는 힘들다.

||<|2><:>GNU||{{{if(...)

   {
       처리();
   }

}}}|| ||블록을 if문 아래에 작성한다. 블록이 if에 속한 블럭임을 분명히 표시하여 구조가 잘 보인다. 허나 들여쓰기를 많이 해서 처리하기에 수평으로 많은 코드를 작성할 수 없다.|| ||<|2><:>K&R||{{{if(...) {

       처리();

} }}}|| ||흔히 C 계열 창시자들이 사용하던 스타일이다. 여는 블록을 if와 같은 행에 배치한다. 코드 줄 수를 절약하여 한눈에 많은 코드를 볼 수 있고 수평으로 많은 코드를 작성할 수 있다. Java 계열 Eclipse / 구글 C++[* [[1]]], 자바스크립트[* [[2]]] 등의 기본 포맷팅이다.|| ||<|2><:>BSD||{{{if(...) {

       처리();

} }}}|| ||GNU의 블럭의 소속을 분명히 한다는 장점과 K&R의 수평으로 많은 코드를 작성할 수 있다는 장점을 가져와 결합한 스타일이다. 줄 수는 GNU 스타일만큼 늘어나지만 수평으로는 K&R만큼 빽빽하게 쓸 수 있다. 비주얼 스튜디오에서의 기본 포맷팅이다.||

위 설명에서는 조건문과 반복문, 함수 등의 차이는 대충 뭉뚱그렸는데, 실제로는 조건문과 반복문, 함수 등에서 들여쓰기의 차이를 두는 경우도 있다.

K&R과 BSD

같은 코드를 K&R과 BSD로 작성하고 비교해 보자.

||<tablewidth=100%>K&R|| ||{{{ if(a == 1) {

   for (i = 0;i < 1000;i++) {
       if (b == 10) {
           처리();
       } else if(c == 10) {
           처리();
       }
   }

} }}}||

||<tablewidth=100%>BSD|| ||{{{ if (a == 1) {

   for (i = 0;i < 1000;i++)
   {
       if (b == 10)
       {
           처리();
       }
       else if(c == 10)
       {
           처리();
       }
   }

} }}}||

BSD 쪽이 좀 더 아래로 길어지는 것을 볼 수 있다. 코드를 종이에 뽑을 일이 있으면 이 문제는 좀 더 중요해진다. --그리고 자기가 소스 코드 몇 줄을 작성하였는지 뽐 낼 때는 BSD를 써서 조금 늘려 자랑한다-- 그래서 출판물에서는 K&R을 선호하는 경향이 있다. 그리하여 대부분의 프로그래밍 언어 교재가 K&R 스타일로 작성되기 때문에 코딩을 갓 접한 학생들이 K&R 스타일에 자연스럽게 익숙해져 있기도 하다. 물론 개인 취향에 따라 나중에 BSD 스타일을 접하고선 갈아타버리기도 한다.

한편, 무슨 일이 생겨서 저 반복문을 반복문이 아니게 해야 한다고 하자. BSD는 for문이 있는 줄만 통째로 지워도 된다.

||<tablewidth=100%>BSD|| ||{{{ if (a == 1) {

   //for (i = 0;i < 1000;i++)
   {
       if (b == 10)
       {
           처리();
       }
       else if(c == 10)
       {
           처리();
       }
   }

} }}}||

그런데 K&R 스타일에서는 그렇게 하면 여는 괄호만 지워지고 닫는 괄호는 안 지워진다. 그래서 리팩토링이 좀 귀찮아진다.

||<tablewidth=100%>K&R|| ||{{{ if(a == 1) {

   //for (i = 0;i < 1000;i++) {
       if (b == 10) {
           처리();
       } else if(c == 10) {
           처리();
       }
   }

} }}}||

변수/함수 명칭의 작성 스타일

변수나 함수명 같은 명칭을 작성할 때 이름을 정의하는 것도 코딩 스타일 중 일부이다.

대표적인 표기법은 다음 네 가지가 있다.

* 카멜 표기법(Camel Case)
여러 단어를 연달아 사용할 때 각 단어의 첫 글자를 대문자로 적되, 맨 앞에 오는 글자는 소문자로 표기하는 것이다. 낙타의 등에 있는 혹과 같다고 하여 카멜(Camel) 표기법이라고 부른다. 예로는 {{{camelVariable}}}과 같은 식으로 쓴다. Java의 권장 표기법이다.

* 파스칼 표기법(Pascal Case)
이 역시 단어의 첫 글자를 대문자로 사용하는 것은 카멜 표기법과 같지만 연달아 오는 단어의 모든 앞글자를 대문자로 표기한다. 카멜 표기법이 단봉낙타라면 파스칼은 쌍봉낙타라고 할 수 있다. 예로는 {{{PowerPoint}}}가 있다. 카멜 표기법과 파스칼 표기법을 적절하게 조합하여, 변수명이나 함수명은 카멜 표기법을 따르고 클래스명은 파스칼 표기법을 따르는 작성 스타일, 혹은 변수명은 카멜로 표기하고 함수와 클래스명은 파스칼로 표기하는 작성 스타일이 대세이다. 전자는 Java, 후자는 C++에서 주로 볼 수 있는 스타일이다. 언어에 따라 전부 카멜, 전부 파스칼로 표기할 것을 권장하기도 한다.

* 헝가리안 표기법(Hungarian Notation)
접두어에 자료형을 붙이는 것으로 {{{strName}}}, {{{bBusy}}}, {{{szName}}} 등이 있다. 요새는 잘 사용하지 않는 (지양하는) 스타일인데 언어의 종류가 다양한 만큼 자료형도, 문서 데이터도 다양해졌기 때문에 접두어가 의미가 없어졌다. 무엇보다 개발 중간 자료형이 바뀐다면(특히 컨테이너 계열에서 자주 일어난다. ArrayList 계열 컨테이너를 LinkedList나 다른 Set, Map, Hash 등의 컨테이너로 바꿀 때) 모든 변수명을 수정해주어야 하는 난감한 상황이 연출된다. 

* 스네이크 표기법(Snake Case)
단어 사이에 언더바를 넣어서 표기하는 것이다. 허나 한 단어에 언더바를 붙인 {{{_apple}}} 등의 명칭은 C++의 장래 예약어 확장을 위해 지양되고 있다. 자세하게는, 언더바를 사용한 후 바로 대문자로 시작하는(e.g. _Apple, _Banana, _Cucumber) 식별자나 인접한 언더바(_a_apple, _b_Banana), 또는 두 개의 언더바(\__Apple, \__banana)는 모든 스코프에서 지양된다. 언더바로 시작하는 모든 식별자는 전역 스코프에서만 지양된다. 식별자는 변수명, 함수명, 데이터타입명, 네임스페이스명 등이 포함된다. 

들여쓰기

들여쓰기를 탭으로 하느냐 스페이스로 하느냐도 주요한 논쟁거리 중 하나이다. 탭으로 들여쓰기를 하면 탭 키 한 번에 끝이고, 반대로 커서를 이동시킬 때도 화살표 키/백스페이스 키 한 번이면 되니 정말 간단하겠지만 IDE, 에디터가 다를 경우 각 시스템의 설정값에 따라 다르게 보일 수 있기에 스페이스로 들여쓰기를 하는 사람도 많다. 실제로 2013년 GitHub에 올라온 코드를 분석한 결과 절대 다수가 탭보다는 스페이스를 선호하는 모습을 보이고 있다. [[3]] 다만 최근의 IDE나 에디터들의 경우 탭 키를 눌러도 스페이스로 처리해 주는 기능이 있기 때문에, 이 문제는 요즘 들어서 크게 논란이 되지는 않고 있다.

대신 요즘에는 들여쓰기를 두 번 하냐 네 번 하냐로 갈린다. HTML 쪽은 코드 라인이 길어지는 경향이 있고, Java 쪽도 언어가 장황한 편이기 때문에 네 번보다는 두 번 들여쓰기를 선호하는 경우가 많다. 구글에서는 코딩 시 스페이스 두 번을 기본 들여쓰기로 사용하고 있다.

한편 탭과 스페이스의 들여쓰기법을 같은 소스 코드에 여기저기 썼다가는 코드에 혼돈의 카오스가 펼쳐지고, 팀 프로젝트일 경우 팀원들로부터 욕이란 욕은 다 먹게 될 가능성이 높으므로 제발 그러지 말자. 물론 어지간한 IDE에서는 코드 리포맷팅을 지원하므로 한 번 돌려주면 깔끔해진다.