[클린코드] 카멜, 파스칼은 가라. 세종대왕 표기법이 온다 (네이밍 컨벤션)

들어가며

전통적인 표기법 4종류, 그리고 클린 코드 표기법으로 인지도를 얻고 있는 독일식 표기법에 대해 알아보겠습니다.

그리고 더 나아가 제가 지어낸 세종대왕 표기법을 사알짝 알아보고 어떤 장점이 있는가 살펴보겠습니다.

페이스북에서 이런 짤을 보셨을 겁니다.

그레이스 천사 = 3월 21일

이렇게 장난스럽게 이름을 지으며 재밌게 놀았던 어린 시절을 기억하시나요?

제갈공명

과거로 가보면

성은 제갈, 이름은 량. 자는 공명, 호는 와룡이었던 촉한의 명재상 "와룡 제갈량 공명??" 선생입니다.

또한 아명(어렸을때 이름)도 있는 바야흐로 이름 짓기 전성시대였습니다. 

이때 이름, 자, 호 등을 다양한 기준과 가치관에 따라 복잡하게 지었고, 또 시간에 따라 변하기도 하였습니다.

이렇게 대상에게 이름을 부여하는 행위는 고금부터 어려운 일이었고, 이는 길흉화복을 점치는 아주 중요한 기준되기도 하였습니다.

하지만 현대에 오면서 이러한 행위들은 사라지고 부르기 쉽고 편한 이름을 오히려 선호하고 있습니다.
( 다만 본래 이름과 달리 글로벌하게 영어 이름은 생겼네요.. 핸디라고)

이렇게 다소 중요함이 떨어진 이름 짓기의 중요함이 대두되고 있는 분야가 있는데 바로 소프트웨어입니다.

과거에는 이름이 사람의 길흉화복을 점치는 기준이었다면, 이젠 코드의 이름이 소프트웨어의 길흉화복을 점치는 기준이 되었습니다.

읽기 어려운 코드는 방치되고 재사용되지 않을 것이며,
읽기 쉬운 코드는 재사용되고 발전할 것이다. 
- 선배 개발자 중에 누군가 왈

이제 잡담은 여기까지 하고 소프트웨어 판에서 가장 기본적인 네이밍 컨벤션에 대해 알아보도록 하겠습니다.

Naming Convention

 : 소스 코드와 문서에 있는 변수 이름, 타입, 함수 등의 식별자에 사용되는 문자열을 선택하기 위한 여러가지 규칙

그리고 Naming Convention(이하 네이밍 컨벤션)은 코딩 컨벤션의 하위 개념 중에 하나입니다.

코딩 컨벤션은 네이밍 컨벤션 / 주석 컨벤션 / 들여쓰기 컨벤션 이 있는데 오늘은 이 중 네이밍 컨벤션만 살펴볼게요.

깊이 들어가기 전에 들여쓰기 컨벤션은 대부분 ide에서 기본적으로 잡아줍니다.

예를 들어 tab 대신에 space 2로 처리, indent의 1depth는 space 2로 처리.

주석 컨벤션의 예시 중에 하나를 가져와봤습니다.

해당 코드가 메인 홈 관련 코드임을 주석으로 명시

하지만 주석 컨벤션의 경우, 사람의 손에 계속해서 필요하고, 최신화되지 않으면 코드를 읽는데 오히려 힘들게 만든다는 치명적인 단점이 있습니다.

또한 예시 사진으로 전달해드린 것처럼 정보 전달의 목적으로 주석을 제공하는 것보다 다른 방법으로 정보전달을 하는 것이 더 좋다는 점으로 인해 점점 사라지고는 있습니다.

그럼 이제 네이밍 컨벤션으로 진짜 들어가 보겠습니다.

기본 설명

이름 그대로 명명규칙,또는 표기법(이하 표기법)입니다.  위키피디아의 설명에 따르면 "사물의 이름을 짓는 합의된 규칙"입니다.

그리고 네이밍 컨벤션(표기법)의 목적은 단 한 가지입니다.

소스 코드를 읽고 이해하는데 드는 노력 절약

다른 목적도 덕지덕지 붙인다면 말이 되지만 결국 근본적인 목적은 소스코드를 쉽게 이해하는 것입니다.

이 목적을 달성하기 위해 가장 간단하고 적용하기 쉬운 방법은 모두가 공유하고 이해 가능한 체계, 규칙을 만들고 그렇게 따르는 것입니다.

하지만 코드를 쉽게 이해하기 위해서 세운 규칙이 어려우면 배보다 배꼽이 큰 상태라 결국 모두가 인정할 만한 컨벤션 몇 개를 남기고 모조리 사라졌습니다.

살아남은 표기법 | 형식적인 표기법

이 순간에서 어디선가 새로운 규칙과 목적을 가진 컨벤션이 나올 수도 있습니다.

1. 카멜 표기법( camelCase )

• 낙타(카멜) 등처럼 내려갔다 올라가는 모양이라 하여 지어진 이름
• 단어가 여러 개 붙을 때, 앞 단어를 제외한 첫자를 대문자로 표기
• java, C#, js 등의 언어들에서 권장

ex) dailyUserTable, getCamelCaseExample

2. 파스칼 표기법( PascalCase )

• 모든 단어의 앞자가 대문자로 시작(단어의 수와 상관없음)
• 네임스페이스, 이벤트, 프로퍼티, 클래스 네임을 지정할 때 주로 사용
• 클래스 등에서 많이 사용

ex) DailyUserTable, PascalCaseExample

3. 스네이크 표기법(snake_case), 팟홀 표기법(pothole_case)

• 모든 단어가 소문자로 표시
• 다른 의미를 갖는 단어들의 조합에서 각 단어의 구분을 위하여 언더바( _ )를 붙임
• 단어 사이의 '_'가 뱀처럼 보인다고 해서 유래
• 언더바 표기법 이라고도 불림
• C++, Python에서 권장

ex) daily_user_table, snake_case_example

4. 헝가리안 표기법

• 접두어에 자료형을 붙임
• 마이크로소프트 개발자 중 헝가리 프로그래머가 쓰던 변수 명명법
• 현재는 안티 패턴으로 죽어가고 있는 표기법, 가끔씩 레거시 코드에서 보임

ex) strDailyUserTable, intCountNumber

 

이렇게 4종의 표기법이 소프트웨어판에서 살아남은 표기법들입니다.

그중 4. 헝가리안 표기법의 경우 가끔씩 보이는 희귀한 표기법입니다.

특히나 타입스크립트가 주류가 되기 전에 큰 문제를 일으킬만한 변수의 경우 자료형을 붙인 경우를 종종 살펴볼 수 있으니 혹시 찾게 되면 행운의 클로바라고 생각하고 기분 좋게 여기시면 됩니다.

---

앞서 설명드린 표기법의 경우 변수의 대소문자, 띄어쓰기로 구분하는 형식적인 표기법이었습니다.

그래서 구분을 위한 규칙을 만들었습니다. 그리고 이 규칙들은 현대에 와서 중요도가 상대적으로 낮아집니다.

왜냐하면 IDE에서 어느 정도 검출이 가능한 시대가 되었기 때문입니다.

예시로, vsc eslint의 @typescript-eslint/naming-convention에서 해당 규칙을 강제할 수 있습니다.

제가 사용하는 eslint rule

그리고 이 룰들 원하는 목적으로 커스텀이 가능합니다.

만약 헝기리안 표기법을 eslint로 잡아내어 에러 처리를 할 수 있을까요?

그럼 간단히 적용해보자면 아래와 같습니다.

custom 에 정규식으로 error 조건 추가

또한 variable name~~ 이 문구도 수정하여, "헝기라안 표기법 극혐, 다른거로 바꾸셈"이라고 error message까지 변경할 수 있습니다.(참 편하죠??)

다시 내용으로 돌아가 이렇게 형식적인 표기법은 이제 검출이 가능하고 수정이 가능한 시대가 되었습니다. 

하지만 사람은 끊임없이 새롭고 편리한 것을 요구하는 존재입니다.

그래서 이런 형식적인 표기법 위에 새로운 표기법을 더하여 조합하여 사용하기 시작합니다.

그게 바로 의미적인 표기법인 아래의 표기법들입니다.

독일식 표기법 | 세종대왕식 표기법 | 의미적인 표기법

뜬금없는 독일과 세종대왕이 나와서 당황하셨으리라 생각합니다.

독일식 표기법은 저 멀리 유럽 쪽에서 나오는 클린 코드 관련된 컨벤션이고 세종대왕식은 제가 그냥 막쓴거든요...

위에서 말씀드렸다시피 어느 정도 자동화가 된 형식적인 표기법 위에, 좀 더 디테일한 조건을 두어 표기하자는 규칙입니다.

목적 | 모든 것을 풀어쓴다

: 해당 함수가 가진 기능을 최대한 세세하게 쓰자는 목적으로 만들어진 표기법(컨벤션)입니다.

독일식 표기법으로 명명된 이유는 유럽 쪽 언어 중에 독일어가 축약이 가장 없는 형태이기 때문입니다.

저는 알 수 없지만 아래와 같은 것들이 있다고 합니다.

• Betäubungsmittelverschreibungsverordnung ("마취제 처방을 요구하는 규정") 
• Rechtsschutzversicherungsgesellschaften ("법적 보호 보험 회사")
• 1999년 독일 "올해의 단어": Rindfleischetikettierungsauflegbengezing의 규정 ")

걱정 | 변수명이 길어지면 불편하지 않냐

과거에는 변수명조차 리소스를 잡아먹기 때문에 축약어를 쓰고, 타입을 쓰고 읽기 쉽게 규칙을 만들어서 표기법을 사용했습니다.

하지만 언어의 발전(자바스크립트-> 타입스크립트) 또는 idea의 자동완성 등으로 변수의 추론이 가능해지고, 길어진 변수명은 자동완성으로 빠르게 타이핑할 수 있게 되면서 쓰기보다는 읽기가 중요한 시대가 되었습니다.

읽기 >>> 쓰기 | 압도적인 중요도 차이

[개발지식] 구글 엔지니어는 이렇게 일한다 - 타이터스 원터스 외2

최근에 읽은 책을 인용해보자면,

구글 개발자들이 내부 통계를 내어 보았을 때 코드는 쓰는 것보다 읽는 것이 수십 배 정도 더 많다는 결과를 얻었다고 합니다.
( 정확한 수치도 언급했었는데, 책을 완독하고 선물해버려서 없네요 ㅜㅜ )

또한 우리도 일하는 것을 고민해보면 실제 코드를 쓰는 것보다 스택오버플로어, 구글에서 찾아서 읽는 시간이 더 많습니다.

오히려 잘 쓰는 것보다는 잘 읽는 것이 중요한 시대가 되었지요.

잘 읽는 것이 중요한 시대에 개발자의 덕목은 잘 읽히는 코드를 만드는 것입니다.

예시 |  풀어쓴다. 익숙한 언어로

잘 읽히는 코드를 위해서 우린 풀어서 써야 합니다. 하지만 풀어서 사용한다고 우리에게 어떤 의미가 있을까요?

이미 사라진 이집트 상형문자나, 바빌로니아의 쐐기문자로 풀어써봐야 해당 언어가 우리에게 익숙하지 않으면 소용이 없습니다.

그래서 저는 해당 팀원들이 한글에 익숙하다는 전제 하에 함수명에 한글을 줄곧 사용하곤 합니다.

객체 키 값에 당당히 한글 때려박기

이젠 코드 예시로 한번 보시죠.

사이트 프로젝트에서 한 해에 거래량이 많은 상위 10개 주식의 거래량 합을 구하는 함수가 있었습니다.

// Total volume of the top 10 stocks with the highest volume in a year
const getTotalVolumnFromTop10StocksWithHighestInYear = () => {
	// 로직 생략
}

여러분은 이 코드가 눈에 들어오시나요?

영어에 익숙하지 않은 저에겐 어렵습니다. 결국 편리함을 위해서 변수명 외에 주석을 추가해야만 하는 어이없는 상황이 생깁니다. 

// 한 해에 거래량 가장 많은 상위 10개 주식의 거래량 합 <- 두번작업!!, 주석컨벤션!!!, 극혐!!!

주석으로 해당 함수를 설명할 거면 함수명을 foo, bar라고 써도 됐을 거예요.

하지만 위의 함수명 getTotalVolumnFromTop10StocksWithHighestInYear 조차 카멜표기법 + 독일식표기법을 합친 것입니다.

함수명에 어떤 목적을 가진 함수인지 전부 다 드려나 있습니다.

하지만 영어 자체가 우리에게 완전히 친숙한 언어가 아니기에 불편함이 생깁니다.

그래서 한글을 코드에 던져봅니다.

// 한 해에 거래량 가장 많은 상위 10개 주식의 거래량 합
// Total volume of the top 10 stocks with the highest volume in a year
const get한해거래량상위10개주식거래량의합계 = () => {
	// 로직 생략
}

뭔가 죄를 짓는 듯한 함수명이 만들어졌습니다.

중국에서 만든 라이브러리인 antd를 최근에 살펴보고 있는데, 중국 형님들은 생각보다 영어 대신 한문 자체를 코드에 사용하는 경우가 생각보다 많이 있습니다.

표의문자인 한문의 경우 짧은 길이에 더 많은 의미를 담을 수 있기 때문에, 한문이 익숙하다면 읽기 더 쉬워지는 효과를 얻을 수 있으리라 혼자 생각해봤습니다.

다시 해당 코드로 돌아가 보겠습니다.

죄를 짓는 느낌과는 별개로 3개월이 지난 지금 해당 코드의 동작을 물어본 사람은 단 한 사람도 없습니다. 미래에도 없을 거라고 생각합니다.

내부적인 동작은 아래 함수로 분리되어 있습니다.

• 주식 거래량의 합계를 구하는 함수
• 한 해 동안 거래량 상위 10개 주식을 반환하는 함수
• 주식의 거래량을 반환하는 함수

하지만 함수를 나누었어도, 맨 처음 콜 하는 함수에선 결국 함수의 목적이 드러내야 하니 결국엔 또 합친 변수명을 쓸 수밖에 없습니다.

돌고 돌아 결국 이해하기 쉽고 읽기 쉬운 변수명을 써야 한다는 점은 변함없죠.

마치며

이번 글에서는 카멜, 파스칼, 스네이크, 헝가리안 등 형식적인 표기법을 살펴보았습니다.

그리고 이런 형식적인 표기법을 강제하기 위한 eslint에 대해서도 간단히 살펴보았네요.

다음으론 클린 코드와 맞물려 인지도를 얻어가는 독일식 표기법을  K-표기법(세종대왕식 표기법)이라는 예시로 설명을 했습니다.

형식적인 표기법이 IDE단에서 검출가능한 것처럼, 언젠가 해당 코드를 읽고 변수명을 판단해주는 eslint툴이 나올수 있을 것도 같아요.

이미 주석 기반으로 코드를 생성해주는 코파일럿같은 툴이 있으니 코드 블록을 읽고 함수명을 판단할수도 있지 않을까 생각해봤습니다.

아직까지 한글을 코드에 쓴다는 행위는 어색합니다. 또 누군가는 싫어하고요.

하지만 팀에서 해보기로 했으니 누가 달려와서 안된다고!! 불편하다고!! 할 때까지 한번 해보렵니다.

끝.

참고자료

German Naming Convention