코딩 스타일

컴퓨터 프로그램의 코드를 작성할 때, 코드가 일관성이 있고 알아보기 쉽도록 여러 가지 스타일을 정하는 규칙. 블럭 정의, 변수나 함수 또는 유형 이름을 표기하는 방식, 들여쓰기를 비롯한 다양한 규칙들을 정할 수 있다. 이는 코드의 문법과는 다른 것인데, 문법을 위반하면 컴파일 또는 실행 오류가 발생하지만 단지 스타일을 어긴 것만으로는 오류가 일어나지 않는다. 기계의 관점으로 보면 하등 영향을 미치지 않지만 사람이 코드를 알아보기 쉽고, 그에 따라 유지보수를 쉽게 하며 여러 명이 참가하는 프로젝트에서 다른 사람이 작성한 코드를 쉽게 이해하거나, 여러 사람이 한 개의 코드 파일을 만졌을 때에도 알아보기 힘든 코드가 되지 않도록 하는 것이 주요한 목적이다. 단, 파이썬은 코딩 스타일 중 몇 가지 요소를 아예 문법으로 집어넣어 버렸다. 다른 언어에서는 블럭 들여쓰기 규칙을 강제하지 않지만 파이썬은 들여쓰기가 곧 블럭의 정의이기 때문에 들여쓰기를 제대로 안 하면 오류를 일으킨다.

과거에는 혼자, 또는 소수의 팀이 프로그램을 만들 수 있었지만 점점 규모가 커지면서 이제는 다수의 개발자, 더 나아가 여러 기업이 같은 프로젝트를 협업 진행하는 사례가 많아졌기 때문에 코딩 스타일 표준화는 더더욱 중요해졌다. 최근에는 각 프로그래밍 언어별로 표준 코딩 스타일을 제정하고 이를 권장하는 분위기다. 몇몇 프레임워크들도 코딩 스타일 매뉴얼을 발표하고 있으며, 기업이나 팀 차원에서 코딩 스타일 규칙을 세우기도 한다. 누가 만든 코드든 일관된 코딩 스타일을 사용함으로써 유지보수와 공동작업을 쉽게 하기 위함이다. 소프트웨어 개발 회사에서도 규모가 좀 있는 곳은 자체 코딩 스타일 규칙을 만들어서 공유하는데, 언어별 표준에서 언급하지 않는 좀 더 자세한 내용을 추가한다든가, 회사의 문화에 따른 이름 붙이기 규칙을 정할 수도 있고, 여러 언어를 활용할 때에는 언어를 포괄하는 공통된 규칙을 정하기도 한다. 경우에 따라서는 프로그래밍 언어가 공식 제안한 스타일과 다른 스타일을 정하기도 한다.

변수∙함수∙유형 표기 방식

변수나 함수, 유형은 띄어쓰기를 허용하지 않는다. 만약 이들의 이름을 여러 단어를 이어서 짓고 싶다면 띄어쓰기 없이도 각 단어를 알아볼 수는 방법이 필요한데, 이를 위해 다양한 방식들이 쓰이고 있다. 한 가지 언어에서 한 가지 표기법만 쓰이는 것은 아니다. 예를 들어 Java는 변수나 함수 이름은 카멜 표기법으로, 클래스 이름은 파스칼 표기법으로 하는 게 기본이다. 이름의 종류에 따라 표기법을 달리 하는 것은 이를 통해 어떤 종류인지 파악하는 데 도움이 되다. 예를 들어 Java라면 카멜 표기법으로 된 이름은 변수나 함수임을, 파스칼 표기법으로 한 것은 클래스임을, 그리고 대문자 스네이크 표기법을 쓴 이름은 static final이나 enum 값, 즉 실제로는 상수임을 쉽게 알 수 있다.

카멜 표기법

Camel case, camelCase

좀 더 공식화된 용어로는 중간 대문자(medial caps)라는 용어도 있다. '카멜'은 '낙타'를 뜻한다. '카멜백 표기법(camelback case)'이라고도 불렀지만 요즘은 거의 쓰이지 않는다. 낙타의 등에 혹이 불룩하게 나와 있는 것에서 따온 이름으로, 각 단어의 첫 글자를 대문자로 표기하되 첫 단어의 첫 글자는 소문자로 표기하는 방식이다. Java가 변수나 함수 이름에 이를 사용하고 있으며, 자바스크립트, C#, Dart와 같은 많은 언어들이 사용하고 있다.

파스칼 표기법

Pascal case, PascalCase

각 단어의 첫 글자를 대문자로 표기한다. 첫 단어의 첫 글자도 대문자로 표기한다. 요즈음은 그냥 이것도 카멜 표기법이라고 부른다. 구분해서 부를 때는 이쪽은 대문자 카멜 표기법(upper camel case)으로, 첫 단어 첫 글자를 소문자로 쓰는 방식은 소문자 카멜 표기법(lower camel case)이라고 부른다. 파스칼 언어에서 이러한 표기법을 사용했기 때문에 붙은 이름이다. 변수나 함수 이름으로는 카멜백 표기법을 사용하는 언어라고 해도 적어도 클래스 이름은 파스칼 표기법을 사용하는 게 보통이다. C#은 변수 이름만 카멜 표기법을 쓰며 메서드 이름이나 클래스 이름은 파스칼 표기법을 쓴다. 또는 기본 유형은 카멜 표기법 또는 스네이크 표기법을 사용하더라도 사용자 정의 유형은 파스칼 표기법을 사용하기도 한다. 당연히 파스칼은 변수 이름도 파스칼 표기법을 사용한다.

스네이크 표기법

Snake case, snake_case

땅바닥을 기어다니는 뱀의 모양과 비슷하다고 해서 붙은 이름. 모두 소문자(혹은 모두 대문자)로 쓰되, 띄어쓰기를 밑줄(_) 기호로 대체하는 것이다. C, C++과 같은 언어들이 이 방법을 사용한다. 변수나 함수, 유형, 클래스 이름은 소문자를, 상수 및 매크로 이름은 대문자를 사용하는 게 관례. Java도 static final 변수(사실상 상수)와 enum 값 이름에 대문자 스네이크 표기법을 쓴다. 파이썬은 변수나 함수 이름은 스네이크 표기법을, 클래스 이름은 파스칼 표기법을 쓰는 관례를 사용한다. 띄어쓰기를 하면 안 되는 파일 이름을 적을 때에도 이 방법을 사용한다. 포트란이나 코볼처럼 문자열을 제외하고 대소문자 구별을 안 하는 언어라면 닥치고 스네이크 표기법.

케밥 표기법

Kebab case, kebab-case

케밥 꼬치의 모양을 보고 따온 말로, 꼬치에 재료가 듬성듬성 꽂혀 있는 것과 비슷한 모양이라는 의미다. 모두 소문자(혹은 모두 대문자)로 쓰되, 띄어쓰기를 하이픈(-) 기호로 대체하는 것이다. 하이픈은 뺄셈 기호로도 쓰이기 때문에 일반 프로그래밍 언어에서는 이름에 잘 안 쓰는 편이며 많은 언어가 변수나 함수, 유형 이름에 하이픈을 못 쓰게 한다. CSS는 연산을 하지 않으므로 이 방식을 사용한다. HTML도 id나 class의 이름은 케밥 표기법을 쓴다. 이들은 주로 CSS에서 쓰이기 때문. URL에도 종종 쓰이며, 띄어쓰기를 하면 안 되는 파일 이름에도 가끔 쓰인다.

헝가리안 표기법

Hungarian notation, strHungarianNotation

영어로는 대소문자를 뜻하는 case 대신에 표기법을 뜻하는 notation을 사용하는데, 이는 대소문자 문제가 아니기 때문이다. 파스칼 표기법처럼 첫 단어를 포함해서 모든 단어의 첫 글자를 대문자로 하되, 그 앞에 변수의 유형을 뜻하는 약어를 소문자로 붙여 준다. 정수(int)형이라면 i, 문자열(string)이라면 str을 붙이는 식이다. 이 방법을 처음 고안한 마이크로소프트의 개발자가 헝가리인이었기 때문에 이런 이름이 붙었다. 윈도우 API에서 이 방식을 사용했으며, MFC에도 썼지만 지금은 잘 안 쓰는 방식이다. 마이크로소프트조차도 이전 윈도우 API와 호환성을 위해서 남겨놓았을 뿐, 더 이상 쓰지 않으며 .NET 프레임워크 프로그래밍에 사용하는 일반 명명 규칙에서 아예 쓰지 말라고 못박았다. 그래도 요즘도 가끔 쓰이는 경우는 있다. 구글은 한때 글로벌 상수 이름 앞에 소문자 k를 붙였는데, 최근에는 가이드라인을 통해 이렇게 하지 말라고 권고하고 있지만 오픈 소스 저장소에 올라와 있는 구글 코드 중에는 여전히 이를 사용한 코드가 종종 보인다. 단, 구글의 C++ 코딩 가이드라인에서는 전역 상수 앞에 k를 붙이도록 하고 있다.

이름

거의 모든 코딩 스타일 가이드는 변수, 함수, 클래스의 이름을 지을 때에는 될 수 있으면 그게 어떤 값을 담고 있거나(변수), 어떤 기능을 하는지(함수, 클래스)를 이름으로 알 수 있도록 이름을 붙일 것을 권장한다. 즉 변수나 함수, 클래스 이름으로, a, b, c 이런 거 쓰지 말라는 뜻이다. 남이 봐도 대체 그게 무슨 값 혹은 기능을 하는지도 모르고 코드가 길어지면 나도 모른다. 단, 정말 특정 함수 안에서 아주 정말 일회성으로 쓰이거나, 루프문을 돌릴 때 인덱스 값으로만 쓸 때와 같은 때에는 예외이긴 하다. 정말 별 의미가 없어서 a, b를 쓸 수도 있다. 예를 들어 두 수의 합을 돌려주는 sum(a, b) 함수의 매개변수는 정말 별 의미가 없기 때문에 a, b를 쓸 수 있다. 하지만 가로 세로 길이를 곱해서 면적을 돌려주는 area(width, height)는 의미 있는 이름을 써 주는 것이 좋다.

이름이 길어지면 줄여서 써도 되는지 여부는 가이드마다 다르다. 자바는 줄임말을 쓰지 않도록 권장하고 있다. 문제는 의미를 알아볼 수 있게 하면서 전체 이름을 다 쓰려면 너무 길어진다는 것. 자바 표준 라이브러리에 있는 것 중에 제일 클래스 이름이 긴 것은 무려 92자로, 'InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState'다. 대체로 이름이 너무 길어지면 적당히 줄임말을 쓴다. 널리 알려진 줄임말은 써도 괜찮다.

들여쓰기

코드 블록 및 블록의 단계를 표시하는 방법으로 들여쓰기가 아주 널리 쓰이고 있다. 그런데 이 들여쓰기를 탭으로 할지 빈칸 문자로 할지에 관한 문제가 있다. 과거에는 탭 문자를 종종 썼지만 탭 문자는 편집기의 설정에 따라서 들여쓰는 칸수가 달라지는 단점이 있다. 빈칸 문자로 채우면 어떤 편집기에서 열든 똑같은 칸수만큼만 들여쓰기가 된다는 게 장점이지만 탭 문자는 한 단계에 한 개만 들어가는 데 반해 빈칸은 들여쓰는 칸수만큼 문자가 들어가야 한다. 저장장치의 용량이 빡빡했던 시절에는 탭 문자가 데이터 용량을 줄여주는 효과를 무시할 일이 아니었기 때문에 탭 문자를 많이 썼지만 지금은 빈칸 문자를 사용하는 방식이 널리 쓰이고 있다. 요즈음의 코딩 스타일 가이드에는 들여쓰기를 몇 칸 해야 하는지까지도 정하고 있으며, 편집기들도 탭 문자를 입력하면 적절한 칸수만큼 빈칸 문자로 채워주는 기능을 제공하고 있다.

옛날에는 탭 하나가 8칸을 차지하는 경우가 많았기 때문에 들여쓰기도 탭 하나 폭, 또는 8칸이었지만 요즘은 코드의 들여쓰기 단계도 늘어나는 편이고, 8칸은 공간 낭비가 많아서 요즘은 2칸이나 4칸을 많이 채택하고 있다.

그밖에

한 줄의 길이가 알파벳 기준으로 80자를 넘지 않을 것을 권장하는 가이드가 많다. 이는 예전부터 터미널이 80자 폭을 쓰는 것에서 유래하는데, 요즈음은 큰 화면으로 한 줄에 많은 글자를 줄바꿈 없이 써도 잘 볼 수 있지만 가독성 면에서는 별로 좋지 않다. 불가피하게 긴 문자열을 써야 한다거나 하는 특별한 예외가 아니면 한 줄이 길지 않게 하는 게 좋다. 알아서 한 줄이 80자를 넘지 않도록 코드를 줄바꿈 해 주는 코드 포매터도 있고, 80자 경계에 선을 그어서 프로그래머가 쉽게 알 수 있도록 하는 코드 편집기들도 있다. 92자짜리 InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState 클래스는 어떻게 해야 하나.