카멜 표기법

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요
2. 종류
- 2.1. 어퍼 카멜 케이스 (Upper Camel Case)
- 2.2. 로어 카멜 케이스 (Lower Camel Case)
3. 역사
- 3.1. 자연어에서의 전통적인 사용
- 3.2. 기술 분야에서의 현대적 사용
4. 현대적 사용
5. 가독성 논란
6. 한국어권에서의 사용
참조

1. 개요

카멜 표기법은 여러 단어를 결합하여 식별자를 만드는 프로그래밍 명명 규칙으로, 각 단어의 첫 글자를 대문자로 표기하여 단어 간의 구분을 나타낸다. 어퍼 카멜 케이스(파스칼 표기법)와 로어 카멜 케이스 두 가지 유형으로 나뉘며, 클래스 이름, 변수 이름, 함수 이름 등 다양한 프로그래밍 요소의 명명에 사용된다. 프로그래밍 언어, 파일 시스템, 위키, 마이크로블로깅 등 다양한 분야에서 활용되며, 가독성에 대한 논란이 존재한다.

더 읽어볼만한 페이지

대문자 사용 - 대소문자
대소문자는 문자를 표기하는 방식으로, 타이포그래피, 언어, 프로그래밍 등 다양한 분야에서 활용되며, 가독성 향상, 강조, 문자열 변환 등에 사용된다.
대문자 사용 - 작은 대문자
작은 대문자는 텍스트 내 특정 요소 강조를 위해 사용되는 활자 스타일로, 출판, 언어학, 법률 문서, 컴퓨터 과학 등 다양한 분야에서 활용되며, 16세기 초부터 사용되어 OpenType 글꼴 표준과 유니코드에서도 지원된다.
타이포그래피 - 팬그램
팬그램은 특정 문자 집합의 모든 문자를 최소 한 번 포함하는 문장이나 구절로, 완전 팬그램, 자기 열거 팬그램 등 여러 유형이 있으며, 다양한 언어에서 활용되고 수학적 연구 주제로도 다뤄진다.
타이포그래피 - ß
ß(에스체트)는 독일어에서 긴 s와 s 또는 z의 합자에서 유래한 문자로, 특정 조건에서 무성음 /s/를 나타내며, 사용 범위가 축소되었으나 대문자 형태(ẞ)가 추가되어 표준 독일어에서 선택적으로 사용될 수 있다.

카멜 표기법
개요
종류	명명 규칙
사용 분야	프로그래밍 데이터베이스 파일 이름 명명
명칭
다른 이름	낙타 표기법 낙타 케이스 카멜 케이스 비대문자 인터캡스 (InterCaps) 혼합 대소문자 파스칼 케이스 (PascalCase, 대문자로 시작하는 경우)
종류
첫 글자 대문자	파스칼 케이스 (PascalCase)
첫 글자 소문자	카멜 케이스 (camelCase)

2. 종류

카멜 표기법은 표기 방식에 따라 크게 두 가지 주요 유형으로 나뉜다. 이는 주로 첫 단어의 첫 글자를 대문자로 쓰는지 소문자로 쓰는지에 따라 구분된다.^[54]^[55]

'''어퍼 카멜 케이스''' (Upper Camel Case, UCC^[54]): 모든 단어의 첫 글자를 대문자로 표기하는 방식이다. 예를 들어 'GetInputReader'와 같이 쓴다. 이 방식은 '''파스칼 표기법'''(PascalCase)이라고도 불린다.^[17]^[18]^[19]
'''로어 카멜 케이스''' (Lower Camel Case, LCC^[55]): 첫 단어는 소문자로 시작하고, 이후 이어지는 단어들의 첫 글자만 대문자로 표기하는 방식이다. 예를 들어 'getInputReader'와 같이 쓴다. 프로그래밍 문맥에서 단순히 '카멜 표기법'이라고 하면 이 로어 카멜 케이스를 가리키는 경우가 많다.^[55]

두 표기법을 명확히 구분하기 위해 '어퍼 카멜 표기법'과 '로어 카멜 표기법'이라는 용어가 사용되기도 한다.

2. 1. 어퍼 카멜 케이스 (Upper Camel Case)

어퍼 카멜 케이스(Upper Camel Case, UCC^[54])는 복합어를 표기할 때 각 단어의 첫 글자를 대문자로 작성하는 방식이다. 첫 단어 역시 첫 글자를 대문자로 시작한다.^[54] 예를 들어, 'GetInputReader'와 같이 표기한다.

이 방식은 '''파스칼 표기법'''(PascalCase)이라는 이름으로도 널리 알려져 있는데,^[17]^[18]^[19] 이는 파스칼 프로그래밍 언어에서 이러한 표기법을 사용한 것에서 유래했다.^[17]^[18]^[19] 파이썬 커뮤니티에서는 '''대문자단어'''(CapitalizedWords) 또는 '''캡워즈'''(CapWords)라고 부르기도 한다.^[10]

마이크로소프트의 .NET 개발 가이드라인에서는 이 표기법을 공식적으로 파스칼 표기법으로 명명하고 있다. 일반적으로 카멜 표기법이라고 하면 첫 단어의 시작을 소문자로 하는 로어 카멜 표기법(Lower Camel Case, LCC^[55])을 가리키는 경우가 많기 때문에, 이와 명확히 구분하기 위해 '어퍼 카멜 표기법'이라는 용어가 사용된다.

명칭	표기 예	비고
어퍼 카멜 표기법(UCC^[54]), 또는 파스칼 표기법	'GetInputReader'	복합어의 각 단어 첫 글자를 대문자로 시작한다.
로어 카멜 표기법(LCC^[55]), 또는 단순히 카멜 표기법	'getInputReader'	첫 단어는 소문자로 시작하고, 이후 단어의 첫 글자를 대문자로 시작한다.

2. 2. 로어 카멜 케이스 (Lower Camel Case)

'''로어 카멜 케이스'''(lower camel case^영어, LCC^[55])는 카멜 표기법의 한 종류로, 복합어로 이루어진 식별자에서 첫 단어는 소문자로 시작하고, 그 이후 각 단어의 첫 글자만 대문자로 표기하는 방식이다. 예를 들어, `getInputReader`와 같이 표기한다.

이 표기법은 파이썬에서 mixedCase|믹스드케이스^영어^[10]라고 불리기도 하며, 프로그래밍 분야에서는 단순히 '카멜 표기법'이라고 할 때 이 로어 카멜 케이스를 가리키는 경우가 많다.^[55] 이는 첫 단어까지 대문자로 시작하는 어퍼 카멜 케이스(파스칼 표기법)와 구분된다.

로어 카멜 케이스는 주로 프로그래밍에서 변수, 함수, 메서드 등의 이름을 짓는 명명 규칙으로 사용된다. 예를 들어, 자바에서는 메서드의 이름을 로어 카멜 표기법으로 작성하는 것이 일반적인 규칙이다.

다음은 로어 카멜 케이스와 어퍼 카멜 케이스를 비교한 표이다.

명칭	표기 예	비고
어퍼 카멜 케이스(UCC^[54]), 또는 파스칼 표기법	GetInputReader	복합어의 첫 글자를 대문자로 시작한다.
로어 카멜 케이스(LCC^[55]), 또는 단순히 카멜 표기법	getInputReader	복합어의 첫 글자를 소문자로 시작한다.

올바른 로어 카멜 케이스 사용 예시는 다음과 같다.

`camelCase` (일반적인 변수 이름)
`isCamelCase` (Boolean 타입의 변수 이름)

잘못된 예시는 다음과 같다.

`camel_case` (스네이크 표기법 형태로 지어진 변수명)

3. 역사

카멜 표기법(Camel Case)의 정확한 기원을 특정하기는 어렵지만, 여러 분야에서 필요에 따라 독립적으로 발생하거나 서로 영향을 주며 발전해 온 것으로 보인다.

기술 분야에서 중간 대문자를 체계적으로 사용한 주목할 만한 초기 사례 중 하나는 1813년 스웨덴 화학자 야코브 베르셀리우스가 제안한 화학식 표기법이다.^[27]^[28] 그는 각 화학 원소를 한두 글자의 기호로 표기하되 첫 글자는 대문자로 쓸 것을 제안했는데, 이는 "NaCl"처럼 여러 원소가 결합된 화학식을 공백 없이 명확하게 표현하기 위한 것이었다. 이 방식은 현대 화학에서도 여전히 사용되고 있다.

자연어에서도 드물지만 특정 언어의 문법적 요구사항이나 표기의 명확성을 위해 단어 중간에 대문자를 사용하는 경우가 있다. 예를 들어 아일랜드어에서 고유 명사에 접두사가 붙을 때나, 독일어에서 남성과 여성을 동시에 지칭하는 단어를 표기할 때 등이 그러하다. (자세한 내용은 자연어에서의 전통적인 사용 섹션 참조)

20세기 초부터는 상업적인 목적으로 상표나 회사명에 카멜 표기법이 간헐적으로 사용되기 시작했다. "DryIce"(1925), "CinemaScope"(1953) 등이 그 예시이다. 이러한 경향은 특히 컴퓨터 기술이 발전하면서 더욱 두드러졌다. (자세한 내용은 상표 및 회사명 섹션 참조)

컴퓨터 프로그래밍 분야에서는 카멜 표기법이 식별자 명명 규칙의 하나로 널리 자리 잡았다. 초기 프로그래밍 언어 환경에서는 식별자에 공백을 사용할 수 없었고, 밑줄_ 문자 사용이 제한적이거나 식별자 길이에 제약이 있는 경우가 많았다.^[56]^[57]^[58] 이러한 상황에서 여러 단어로 이루어진 식별자의 가독성을 높이기 위한 방안으로 카멜 표기법이 등장했다. 특히 1970년대 Xerox PARC에서 개발된 Mesa나 Smalltalk 같은 언어들이 밑줄 대신 카멜 표기법을 적극적으로 사용하면서^[34] 이 방식이 널리 퍼지는 계기가 되었다고 알려져 있다. (자세한 내용은 컴퓨터 프로그래밍 섹션 참조)

이후 개인용 컴퓨터의 대중화와 인터넷의 발달을 거치며 카멜 표기법은 프로그래밍 커뮤니티를 넘어 다양한 기술 용어, 제품명, 서비스명 등에 보편적으로 사용되게 되었다.

3. 1. 자연어에서의 전통적인 사용

일반 텍스트에서 중간 대문자를 사용하는 관례는 드물지만, 두 단어나 세그먼트가 결합될 때 발생하는 특정 문제를 해결하기 위해 일부 언어에서 사용된다.

이탈리아어에서는 대명사가 동사에 접미사로 붙을 수 있으며, 2인칭 존칭 대명사는 대문자로 표기되므로, ''non ho trovato il tempo di risponderLe'' ("답변할 시간이 없었다" - 여기서 ''Le''는 "당신에게"를 의미함)와 같은 문장이 나올 수 있다.

독일어에서는 중간 대문자 I인 ''Binnen-I''가 때때로 ''StudentInnen'' ("학생들")과 같은 단어에서 ''Studenten'' ("남학생")과 ''Studentinnen'' ("여학생")을 동시에 나타내기 위해 사용된다. 그러나 중간 단어 대문자 표기는 ''McDonald''와 같은 고유 명사를 제외하고는 독일어 정서법에 부합하지 않는다. 앞의 예는 영어의 "congress(wo)men"과 유사하게 괄호를 사용하여 ''Student(inn)en''으로 올바르게 작성할 수 있다.^[25]

아일랜드어에서는 굴절 접두사가 고유 명사에 붙을 때 카멜 표기법이 사용된다. 예를 들어 i nGaillimh|i nGaillimh^gle ("골웨이에서"), Gaillimh|Gaillimh^gle ("골웨이"); an tAlbanach|an tAlbanach^gle ("스코틀랜드 사람"), Albanach|Albanach^gle ("스코틀랜드 사람"); 그리고 go hÉirinn|go hÉirinn^gle ("아일랜드로"), Éire|Éire^gle ("아일랜드")가 있다. 최근 스코틀랜드 게일어 정서법에서는 하이픈이 삽입되었다: an t-Albannach|an t-Albannach^gle.

굴절 접두사의 이 관례는 여러 반투어 (예: ''isiZulu'', "줄루어")와 여러 원주민 멕시코 언어 (예: 나와틀어, 토토나크어, 믹스-조크어, 일부 오토망게어)에서도 사용된다.

네덜란드어에서는 이중자 ''ij''를 대문자로 표기할 때 문자 ''I''와 문자 ''J''를 모두 대문자로 표기한다. 예를 들어 국가 이름 ''IJsland'' ("아이슬란드")가 있다.

중국어 병음에서는 지명에 카멜 표기법을 사용하여 독자들이 이름의 다른 부분을 더 쉽게 구분할 수 있도록 한다. 예를 들어 베이징(北京), 친황다오(秦皇岛), 다싱안링(大兴安岭)과 같은 장소는 각각 ''BeiJing'', ''QinHuangDao'', ''DaXingAnLing''으로 쓸 수 있으며, 대문자 수는 한자 수와 같다. 각 문자의 첫 글자로만 단어 복합어를 쓰는 것도 경우에 따라 허용되므로 베이징은 ''BJ'', 칭황다오는 ''QHD'', 다싱안링은 DXAL로 쓸 수 있다.

영어에서는 중간 대문자는 일반적으로 스코틀랜드 또는 아일랜드의 "Mac-" 또는 "Mc-" 성에서 발견된다. 예를 들어 ''MacDonald, McDonald'' 및 ''Macdonald''는 MacDonald (Dòmhnall의 아들)의 일반적인 철자 변형이며, 앵글로-노르만 "Fitz-" 성에서도 발견된다. 예를 들어 ''FitzGerald''와 ''Fitzgerald'' (Gerald의 아들)가 있다.

1906년에 처음 출판된 그들의 영어 스타일 가이드인 ''The King's English''에서 H. W.와 F. G. Fowler는 중간 대문자를 복합어가 3개인 경우 하이픈이 모호성을 야기할 수 있는 경우에 사용할 수 있다고 제안했다. 그들이 제시한 예는 ''KingMark-like'' (''King Mark-like''와 반대)와 ''Anglo-SouthAmerican'' (''Anglo-South American''과 반대)이다. 그러나 그들은 이 시스템을 "현재 사용하기에는 너무 희망이 없다"고 설명했다.^[26]

일부 프랑스 이름에서도 LeBeau (surname), LaRue, DeMordaunt 및 이탈리아 이름 DeRose/DeRosa와 같이 카멜 표기법 이름을 사용한다.

다른 문자로 쓰인 언어의 학술적인 음역에서, 중간 대문자는 비슷한 상황에서 사용된다. 예를 들어, 음역된 히브리어에서 ''haIvri''는 "히브리인" 또는 "유대인"을 의미하고 ''b'Yerushalayim''은 "예루살렘에서"를 의미한다. 표준 티베트어에서 ''rLobsang''과 같은 고유 명사에서 "r"은 원래 문자에서 일반적인 문자가 아닌 성조 표시자 역할을 하는 접두사 글리프를 나타낸다. 또 다른 예는 체첸어의 용어인 ''tsIurku''로, 체첸과 잉구셰티아의 특징적인 중세 방어탑의 덮개돌을 라틴 문자로 표기한 것이다; 문자 "I" (팔로치카)는 실제로 대문자가 아니며, "i"로 표기된 것과는 다른 음소를 나타낸다.

중간 대문자는 약어에서 전체 단어를 다 쓸 때의 대문자 표기를 반영하기 위해 전통적으로 사용된다. 예를 들어, 학위 칭호인 PhD 또는 BSc가 있다. 더 최근의 예로는 NaNoWriMo가 있는데, 이는 National Novel Writing Month의 축약형이며, 연례 행사와 이를 운영하는 비영리 단체 모두를 지칭한다. 독일에서는 법률 이름을 중간 대문자를 사용하여 축약한다. 예를 들어, StGB는 Strafgesetzbuch|슈트라프게제츠부흐^deu (형법), PatG는 Patentgesetz|파텐트게제츠^deu (특허법), BVerfG는 Bundesverfassungsgericht|분데스페어파숭스게리히트^deu (연방 헌법 재판소), 또는 매우 흔한 GmbH는 Gesellschaft mit beschränkter Haftung|게젤샤프트 미트 베슈렝크터 하프퉁^deu (유한 회사)이다. 이 맥락에서, TzBfG for Teilzeit- und Befristungsgesetz|타일차이트 운트 베프리스퉁스게제츠^deu (단시간 및 기간제 고용법)와 같이 세 개 이상의 카멜 케이스 대문자가 있을 수도 있다. 프랑스어에서는 OuLiPo (1960)와 같은 카멜 케이스 두문자어가 머리글자어의 대안으로 한동안 선호되었다.

카멜 케이스는 두 글자가 원래 알파벳의 단일 문자를 나타내야 하는 알파벳으로 두문자어를 음역하는 데 자주 사용된다. 예를 들어, DShK는 키릴 문자 ДШК에서 유래되었다.

3. 2. 기술 분야에서의 현대적 사용

프로그래밍 분야에서 카멜 표기법은 식별자의 명명 규칙 중 하나로 널리 사용된다. 많은 프로그래밍 언어는 식별자에 공백을 허용하지 않기 때문에, 여러 단어로 이루어진 식별자의 가독성을 높이기 위한 방법이 필요했다. 초기 컴퓨터 환경에서는 언더스코어_ 사용이 불가능하거나 식별자 길이에 제한이 있는 경우가 많아, "getinputreader"처럼 단어를 그대로 붙여 쓰는 방식이 사용되기도 했으나 가독성이 떨어졌다.^[56]^[57]^[58] 이에 따라 대소문자를 구분할 수 있는 환경에서는 각 단어의 첫 글자를 대문자로 표기하는 카멜 표기법(예: `getInputReader` 또는 `GetInputReader`)이 고안되어 문자 수를 절약하면서 가독성을 높이는 방식으로 자리 잡았다.

파일 시스템에서도 파일이나 디렉터리(폴더) 이름에 카멜 표기법이 사용되는 경우가 있다. 특히 명령줄 인터프리터 환경에서는 공백이 포함된 이름이 문제를 일으킬 수 있어, 카멜 표기법이 유용하게 쓰인다. 다만, 운영 체제나 파일 시스템에 따라 대소문자를 구분하지 않는 경우도 있어 주의가 필요하다.

초창기 위키에서는 카멜 표기법으로 작성된 단어를 자동으로 하이퍼링크로 만드는 기능(WikiCase)이 사용되기도 했으나, 현재는 미디어위키처럼 ``와 같은 명시적인 링크 문법을 사용하는 방식이 더 일반적이다.

현대에 들어서는 기술 분야 외에도 다양한 상품명이나 서비스명에서 카멜 표기법을 쉽게 찾아볼 수 있다. 예를 들어 플레이스테이션(PlayStation), 아이폰(iPhone), 유튜브(YouTube) 등이 대표적이다. 이는 브랜드 이름을 공백 없이 하나의 고유 명사로 만들어 웹 검색 엔진 등에서 쉽게 식별되도록 하는 장점도 있다.

3. 2. 1. 화학식

1813년 스웨덴의 화학자 야코브 베르셀리우스가 발명한 화학식 표기법은 기술적인 목적으로 중간 대문자를 체계적으로 널리 사용한 최초의 사례였다. 당시까지 화학자들이 사용하던 수많은 명명 및 기호 관례를 대체하기 위해, 그는 각 화학 원소를 한두 글자의 기호로 표시하고 첫 글자를 대문자로 표기할 것을 제안했다. 대문자 표기법을 통해 "NaCl"과 같은 화학식을 공백 없이 작성하고도 모호함 없이 해석할 수 있게 되었다.^[27]^[28]

베르셀리우스의 시스템은 현재까지 사용되고 있으며, 확인되지 않았거나 알려지지 않은 원소에 대한 "Uue"와 같은 세 글자 기호 및 일부 일반적인 치환체에 대한 약어(특히 유기 화학 분야에서, 예를 들어 "Et"는 "에틸-")가 추가되었다. 이는 아미노산 서열의 단백질 및 기타 유사한 영역을 설명하는 데 더욱 확장되었다.

3. 2. 2. 상표 및 회사명

20세기 초부터 단어 중간에 대문자를 사용하는 방식(중간 대문자)은 기업 이름이나 제품 상표에 드물게 사용되기 시작했다. 예를 들면 다음과 같다.

DryIce Corporation (1925)은 이산화 탄소 (CO₂)의 고체 형태를 "Dry Ice"라는 이름으로 판매했으며, 이는 이후 일반적인 이름이 되었다.^[29]
시네마스코프(CinemaScope)와 비스타비전(VistaVision) (1953)은 경쟁 관계에 있던 와이드스크린 영화 형식의 이름이다.
ShopKo (1962)는 소매점 이름이었으나 나중에 Shopko로 변경되었다.
''Mister Rogers' Neighborhood'' (1968)는 TV 시리즈 제목이다.^[30]
ChemGrass (1965)는 나중에 AstroTurf (1967)로 이름이 바뀐 제품이다.
ConAgra (1971)는 Consolidated Mills가 이름을 바꾼 것이다.
MasterCraft (1968)는 스포츠 보트 제조 업체의 이름이다.
AeroVironment (1971)
PolyGram (1972)은 Grammophon-Philips Group이 이름을 바꾼 것이다.
United HealthCare (1977)^[31]
MasterCard (1979)는 Master Charge에서 이름이 변경되었다.
SportsCenter (1979)

컴퓨터 분야에서 시작되었는지 여부와 관계없이, 1970년대 후반부터 컴퓨터 관련 회사나 상업 브랜드 이름에 카멜 표기법이 사용되기 시작했으며, 이러한 경향은 현재까지 이어지고 있다.

(1977) 컴퓨서브(CompuServe)
(1978) 워드스타(WordStar)
(1979) 비지칼크(VisiCalc)
(1982) 마이크로프로즈(MicroProse), 워드퍼펙트(WordPerfect)
(1983) 네트웨어(Novell NetWare)
(1984) 레이저젯(LaserJet), 맥웍스(MacWorks), 포스트스크립트(PostScript)
(1985) 페이지메이커(Adobe PageMaker)
(1987) 클라리스웍스(ClarisWorks), 하이퍼카드(HyperCard), 파워포인트(PowerPoint)
(1990) 월드와이드웹(WorldWideWeb) (최초의 웹 브라우저 이름, 이후 넥서스(Nexus)로 변경)

1980년대와 1990년대에 개인용 컴퓨터가 널리 보급되면서 카멜 표기법은 컴퓨터 분야를 넘어 일반 기업의 상표에도 유행처럼 사용되기 시작했다. 1990년경에는 이미 널리 사용되는 방식이 되었다.

(1980) 에코스타(EchoStar)
(1984) 벨사우스(BellSouth)
(1985) ''이스트엔더스(EastEnders)'' (TV 시리즈)
(1986) ''스페이스 캠프(SpaceCamp)'' (영화 제목)
(1990) 하퍼콜린스(HarperCollins), 시택(SeaTac) (지명)
(1998) 프라이스워터하우스쿠퍼스(PricewaterhouseCoopers) (프라이스 워터하우스(Price Waterhouse)와 쿠퍼스(Coopers)의 합병으로 탄생)

1990년대 후반 닷컴 버블 시기에는 'e'(전자)나 'i'(인터넷,^[36] 정보, 지능 등을 의미)를 소문자 접두사로 붙이는 것이 매우 흔해졌다. 예를 들어 애플의 iMac이나 eBox 소프트웨어 플랫폼 같은 이름들이 등장했다.

오늘날에도 카멜 표기법은 플레이스테이션(PlayStation), 아이폰(iPhone), 블랙베리(BlackBerry), 원드라이브(OneDrive), 유튜브(YouTube) 등 다양한 상품명과 서비스명에서 흔히 찾아볼 수 있다. 이러한 표기법은 공백 없이 하나의 단어로 인식되어 웹 검색 엔진에서 쉽게 구분될 수 있다는 장점도 있다.

3. 2. 3. 컴퓨터 프로그래밍

프로그래밍에서 캐멀 표기법은 식별자의 명명 규칙 중 하나로 사용된다. 식별자는 변수(variable), 서브루틴, 사용자 정의 데이터형과 같은 구문 요소를 구별하는 이름이지만, 많은 프로그래밍 언어에서는 공백이 토큰(token)의 구분자로 사용되므로 하나의 식별자에 공백을 포함할 수 없다.^[56]

end of file이나 char table처럼 공백이 포함된 여러 단어로 구성된 설명적인 식별자는 대부분의 프로그래밍 언어에서 사용할 수 없다. 단어 사이의 공백이 파서에 의해 토큰 사이의 구분 기호로 구문 분석되기 때문이다. endoffile이나 chartable처럼 단어를 단순히 이어 붙이는 방법은 이해하기 어렵고 오해의 소지가 있을 수 있다. 예를 들어, chartable은 영어 단어(chartable^eng, 차트로 만들 수 있는)로 해석될 수 있지만, 의도한 의미는 charTable(문자들의 테이블)일 수 있다.

일부 초기 프로그래밍 언어, 특히 Lisp(1958)와 COBOL(1959)은 "END-OF-FILE"처럼 복합 식별자의 단어 사이에 하이픈("-")을 사용하여 이 문제를 해결했다. Lisp는 접두사 표기법과 잘 작동했고(Lisp 파서는 기호 중간의 하이픈을 빼기 연산자로 처리하지 않음), COBOL은 연산자가 개별 영어 단어였기 때문에 가능했다. 이 규칙은 해당 언어들에서 여전히 사용되며, 유닉스와 같이 명령줄에 입력되는 프로그램 이름에서도 흔히 볼 수 있다.

그러나 이 해결책은 하이픈을 중위 빼기 연산자로 사용하는 수학 지향적 언어인 FORTRAN(1955) 및 ALGOL(1958)에는 적합하지 않았다. FORTRAN은 공백을 완전히 무시했기 때문에 프로그래머는 변수 이름에 공백을 포함할 수 있었지만, 언어 초기 버전에서는 식별자를 6자 이하로 제한했기 때문에 이 기능은 그다지 유용하지 않았다. 당시 흔했던 천공 카드 문자 집합은 대문자만 지원하고 다른 특수 문자가 부족했던 점도 제약이었다. 1960년대 후반에 이르러 ASCII 문자 집합이 널리 채택되면서 소문자와 밑줄 문자 _가 보편적으로 사용 가능해졌다. C와 같은 일부 언어는 밑줄을 단어 구분 기호로 채택했으며, end_of_file과 같은 식별자는 C 프로그램과 라이브러리(그리고 Perl 및 Python과 같이 C의 영향을 받은 후속 언어)에서 여전히 널리 사용된다. 그러나 일부 언어와 프로그래머는 밑줄 사용을 피하고 대신 카멜 표기법을 채택했다.

1970년대와 1980년대에 여러 프로그래밍 언어에서 여러 단어로 구성된 식별자의 표준 또는 대체 명명 규칙으로 중간 대문자(카멜 표기법의 초기 형태)가 채택되었다. 이 규칙의 정확한 기원은 불분명하지만, 1954년 회의록^[32]에서는 IBM의 Speedcoding 시스템을 "SpeedCo"로 비공식적으로 언급했으며, 크리스토퍼 스트레이치의 GPM에 대한 1965년 논문^[33]에는 "NextCh" 및 "WriteSymbol"과 같은 중간 대문자 식별자가 포함된 프로그램이 등장한다.

카멜 표기법 스타일은 1978년경 Xerox PARC에서 Xerox Alto 컴퓨터용으로 개발된 Mesa 프로그래밍 언어와 함께 처음 대중화되었다고 알려졌다. Alto 컴퓨터에는 밑줄 키가 없었고(왼쪽 화살표 "←"로 대체됨) 하이픈과 공백 문자는 식별자에 허용되지 않아, 카멜 표기법이 여러 단어로 구성된 이름을 읽기 쉽게 만드는 유일한 방법이었다. PARC Mesa 언어 매뉴얼(1979)에는 Mesa 라이브러리와 Alto 운영 체제에서 엄격하게 준수되는 상위 및 하위 카멜 표기법에 대한 특정 규칙이 포함된 코딩 표준이 포함되어 있었다. 파스칼의 창시자인 니클라우스 비르트는 PARC에서의 안식년을 통해 카멜 표기법을 접하고 다음 프로그래밍 언어인 Modula에서 이를 사용했다.^[34] Alto에서 처음 개발된 Smalltalk 언어 역시 밑줄 대신 카멜 표기법을 사용했다. 이 언어는 1980년대 초에 상당한 인기를 얻었으며, PARC 외부로 카멜 표기법 스타일을 확산시키는 데 기여했을 수 있다.

식별자에 사용할 수 있는 문자 종류나 수에 제한이 있는 환경에서 복합어를 하나의 프로그램 요소로 만들 때, "getinputreader"처럼 직접 연결하는 방법은 단어 경계를 인식하기 어려워 가독성을 해친다. 밑줄이나 하이픈을 사용할 수 있다면 "get_input_reader"나 "GET-INPUT-READER"처럼 구분자를 사용할 수 있지만, 문자 수가 늘어나는 단점이 있다. 대소문자를 구분할 수 있는 환경에서는 후속 단어의 첫 글자를 대문자로 표기하는 카멜 표기법(예: getInputReader)이나 파스칼 표기법(예: GetInputReader)을 사용하면 문자 수를 절약하면서 단어 구분을 명확히 할 수 있다. 이러한 표기법은 나중에 "카멜 표기법"과 "파스칼 표기법"으로 명명되었지만, 그 이전부터 mixed case^eng 등으로 불렸다.^[61]

파스칼 표기법(PascalCase)이라는 용어는 프로그래밍 언어 파스칼에서 유래했다.^[17]^[18]^[19] 파스칼은 원래 대소문자를 구분하지 않고, ISO 표준 규격에서는 식별자에 밑줄_을 사용할 수 없었기 때문에^[62], 단어 경계를 인식하기 쉽게 하기 위해 단어의 첫 글자를 대문자로 하는 관습이 생겼다. 일부 파스칼 처리계 문서에서는 표준 프로시저(procedure) 이름을 WriteLn과 같이 어퍼 카멜 케이스(Upper Camel Case)로 표기하기도 했다.^[63]^[64]

현대 프로그래밍 언어에서도 카멜 표기법은 널리 사용된다. 비주얼 베이직은 윈도 API 및 OLE/COM의 영향을 받았고, .NET Framework와 .NET 언어(C#/VB.NET 등)는 델파이(Object Pascal)의 영향을 받아 메서드 이름을 대문자로 시작하는 어퍼 카멜 표기법(파스칼 표기법)을 사용하는 경향이 있다. 반면, Java는 메서드 이름을 소문자로 시작하는 로워 카멜 표기법(카멜 표기법)을 주로 사용한다. 하지만 이들 언어 대부분에서 사용자 정의 타입의 이름은 대문자로 시작하는 어퍼 카멜 표기법을 권장한다. C#에서는 변수 이름에 소문자 카멜 표기법 규칙을 따르는 것이 권장된다.^[35] 컴퓨터 대수 시스템 Mathematica의 울프럼 언어에서는 미리 정의된 식별자에 대문자 카멜 표기법(파스칼 표기법)을 사용하며, 사용자가 정의하는 식별자는 소문자로 시작하도록 하여 이름 충돌을 방지한다.

파일 시스템에서 파일 및 디렉터리(폴더) 이름에 카멜 표기법이 사용되기도 한다. 특히 명령줄 인터프리터로 파일 시스템을 조작할 때 공백이 포함된 이름은 문제를 일으킬 수 있으므로, 문자 수를 절약하면서 가독성을 확보할 수 있는 카멜 표기법이 유용할 수 있다. 그러나 운영 체제 및 파일 시스템에 따라 대소문자를 구분하지 않거나 모두 대문자로 처리하는 경우도 있어 주의가 필요하다.

초창기 위키에서는 카멜 표기법으로 작성된 단어를 하이퍼링크로 자동 변환하는 기능(WikiWord 또는 WikiCase^[20]^[21])이 사용되기도 했으나, 현재는 미디어위키처럼 와 같은 명시적인 링크 문법을 사용하는 방식이 일반적이다.

4. 현대적 사용

카멜 표기법은 현대 컴퓨터 과학 및 정보기술(IT) 분야에서 널리 사용되는 명명 규칙 중 하나이다.

특히 프로그래밍 분야에서 변수, 함수, 클래스 등의 식별자를 명명하는 데 활발히 사용된다. 많은 코딩 스타일 가이드라인에서는 특정 요소(예: 클래스 이름 vs. 변수 이름)에 따라 첫 글자를 대문자로 쓰는 어퍼 카멜 케이스(Upper Camel Case, 파스칼의 이름을 따 파스칼케이스(PascalCase)라고도 함^[17]^[18]^[19])와 소문자로 쓰는 로어 카멜 케이스(lower camel case)를 구분하여 사용하도록 권장한다. 자바, 마이크로소프트(Microsoft)의 .NET 환경 등 여러 프로그래밍 환경에서 이러한 규칙을 따르고 있다. 두문자어 및 약어(예: HTML, XML)를 포함하는 식별자를 어떻게 표기할지(예: `oldHTMLFile` vs. `oldHtmlFile`)에 대해서는 개발자들 사이에서 선호도가 갈리기도 한다.^[38]^[39]

과거 일부 위키 시스템에서는 카멜 표기법으로 작성된 단어(위키워드, WikiWord^[20] 또는 위키케이스, WikiCase^[21])를 자동으로 하이퍼링크로 만드는 기능을 사용했으나, 현재는 미디어위키처럼 명시적인 링크 문법을 사용하는 경우가 더 일반적이다.

파일 시스템에서 공백 없이 파일이나 디렉터리 이름을 지정하거나, 글자 수 제한이 있는 마이크로블로깅 서비스의 해시태그에서 가독성을 높이기 위해 사용되기도 한다. 이 외에도 상품명이나 서비스명(예: 아이폰, 유튜브) 등 다양한 분야에서 활용되고 있다.

4. 1. 프로그래밍

프로그래밍에서 카멜 표기법(Camel Case)은 식별자의 명명 규칙 중 하나로 널리 사용된다. 식별자는 변수, 서브루틴, 사용자 정의 데이터형 등 프로그램의 구성 요소를 구분하는 이름을 뜻한다. 대부분의 프로그래밍 언어는 공백을 토큰 구분자로 사용하므로, 식별자 이름 안에 공백을 포함할 수 없다. 이 때문에 'end of file'이나 'char table'처럼 여러 단어로 이루어진 이름을 하나의 식별자로 만들 때 가독성 문제가 발생한다. 단순히 `endoffile`이나 `chartable`로 붙여 쓰면 단어 구분이 어려워지고, `chartable`처럼 의도치 않은 다른 의미(차트 작성이 가능한)로 해석될 수도 있다.

이 문제를 해결하기 위해 여러 방법이 사용되었다. Lisp나 COBOL 같은 초기 언어에서는 단어 사이에 하이픈("-")을 넣어 `END-OF-FILE`처럼 사용했다.^[56] 하지만 FORTRAN이나 ALGOL처럼 하이픈을 빼기 연산자로 사용하는 언어에서는 이 방식이 적합하지 않았다. C 언어가 등장한 이후로는 밑줄 문자(`_`)를 단어 구분자로 사용하는 스네이크 표기법(snake_case), 예를 들어 `end_of_file` 같은 방식이 널리 쓰이게 되었고, 이는 Perl이나 Python 등 C의 영향을 받은 언어들에서도 흔히 볼 수 있다.

카멜 표기법은 이러한 배경 속에서 등장했다. 특히 1970년대 Xerox PARC에서 개발된 Mesa 프로그래밍 언어와 Xerox Alto 컴퓨터 환경에서 카멜 표기법이 적극적으로 사용된 것으로 알려져 있다. 당시 Alto 컴퓨터 키보드에는 밑줄 키가 없었고, 하이픈이나 공백 문자를 식별자에 사용할 수 없었기 때문에, 여러 단어로 이루어진 이름을 읽기 쉽게 만드는 유일한 방법이 카멜 표기법이었다. PARC에서 발행된 Mesa 언어 매뉴얼(1979)에는 카멜 표기법 사용에 대한 구체적인 코딩 표준이 포함되어 있었으며, 이는 Mesa 라이브러리와 Alto 운영체제 전반에 걸쳐 적용되었다. 파스칼 언어를 개발한 니클라우스 비르트는 PARC에서의 연구 활동을 통해 카멜 표기법의 유용성을 접하고, 이후 자신이 개발한 Modula 언어에 이를 도입했다.^[34] 또한, Alto에서 처음 개발된 Smalltalk 언어도 밑줄 대신 카멜 표기법을 사용했으며, 1980년대 Smalltalk의 인기는 카멜 표기법 확산에 기여했을 것으로 보인다.

많은 조직이나 소프트웨어 프로젝트에서는 코딩 스타일 가이드라인을 통해 카멜 표기법 사용을 권장한다. 특히 메사, 파스칼, 모듈라, 자바, 그리고 마이크로소프트(Microsoft)의 .NET 같은 환경에서는 언어 개발자나 공식 문서에서 카멜 표기법 사용을 권장하여 언어 문화의 일부로 자리 잡았다. 스타일 가이드라인은 종종 첫 글자를 대문자로 시작하는 어퍼 카멜 케이스(Upper Camel Case, 또는 파스칼 케이스 PascalCase)와 첫 글자를 소문자로 시작하는 로어 카멜 케이스(lower camel case, 또는 좁은 의미의 카멜 케이스 camelCase)를 구분하여 사용하도록 명시한다. 예를 들어, 클래스나 타입 이름에는 어퍼 카멜 케이스를, 메서드나 변수 이름에는 로어 카멜 케이스를 사용하는 식이다. 이러한 규칙은 정적 코드 분석 도구를 통해 준수 여부를 검사하기도 한다.

Java: 클래스 이름은 어퍼 카멜 케이스(`PersonClass`), 메서드와 변수 이름은 로어 카멜 케이스(`getPersonName`, `personAge`)를 사용한다.
.NET (C#, VB.NET 등): 델파이(오브젝트 파스칼)의 영향을 받아 클래스와 메서드 이름 모두 어퍼 카멜 케이스(`PersonClass`, `GetPersonName`)를 사용한다. 다만, C#의 지역 변수나 매개변수 이름에는 로어 카멜 케이스(`personAge`) 사용이 권장된다.^[35]
파스칼: 언어 자체는 대소문자를 구분하지 않지만, 표준 규격에서 식별자에 밑줄 사용이 불가능^[62]하여 가독성을 위해 단어의 첫 글자를 대문자로 쓰는 관습(`WriteLn`^[63]^[64])이 생겨났고, 이것이 '파스칼 케이스'라는 이름의 유래가 되었다.
울프럼 언어 (Mathematica): 내장 함수나 상수는 어퍼 카멜 케이스를 사용하고, 사용자가 정의하는 식별자는 소문자로 시작하도록 권장하여 이름 충돌을 방지한다.

찰스 시모니가 고안한 헝가리안 표기법의 한 버전에서는 변수 이름 시작 부분에 해당 변수의 '사용 유형'을 나타내는 소문자 약어를 붙이고, 나머지 부분은 어퍼 카멜 케이스로 작성한다. 이는 로어 카멜 케이스의 한 형태로 볼 수 있다.

카멜 표기법을 사용할 때 두문자어 및 약어(예: HTML, XML, SQL)를 처리하는 방식에 대한 논의가 있다. 예를 들어 "old HTML file"을 식별자로 만들 때, 자연스럽게는 약어 전체를 대문자로 써서 `oldHTMLFile`로 표기할 수 있다. 하지만 "parse DBM XML"처럼 약어가 연달아 나오면 `parseDBMXML`이 되어 가독성이 떨어질 수 있다. 또한 로어 카멜 케이스 규칙을 따를 때 이름이 약어로 시작하면(예: "SQL server") `sQLServer`처럼 어색한 형태가 될 수 있다. 이런 이유로 일부 개발자들은 약어도 일반 단어처럼 취급하여 첫 글자만 대문자로 쓰는 `oldHtmlFile`, `parseDbmXml`, `sqlServer` 같은 방식을 선호하기도 한다.^[38] 그러나 이 방식은 해당 부분이 약어임을 인지하기 어렵게 만들 수 있다는 단점도 있다.^[39]

모든 개발자가 카멜 표기법을 선호하는 것은 아니다. C++ 언어 설계자인 비야네 스트롭스트룹은 식별자 내 단어 구분에 밑줄을 사용하는 것(`element_count`)을 더 선호한다고 밝힌 바 있다.^[59]^[60] 실제로 표준 C++ 라이브러리에는 `std::runtime_error`나 `std::vector::push_back()`처럼 밑줄을 사용한 이름이 많이 사용된다. 다만 스트롭스트룹 역시 사용자 정의 타입의 이름은 표준 라이브러리와의 충돌을 피하기 위해 첫 글자를 대문자로 시작할 것을 권장하기도 한다.

파일 시스템에서 파일이나 디렉터리(폴더) 이름을 정할 때도 카멜 표기법이 사용되기도 한다. 특히 명령줄 인터프리터 환경에서는 이름에 공백이 있으면 다루기 까다롭기 때문에, 공백 없이 단어를 구분할 수 있는 카멜 표기법이 유용할 수 있다. 하지만 운영 체제나 파일 시스템에 따라 대소문자를 구분하지 않거나 모두 대문자로 처리하는 경우도 있어 주의가 필요하다.

초기 위키 시스템 중 일부는 카멜 표기법으로 작성된 단어(WikiWord)를 자동으로 하이퍼링크로 만드는 기능을 사용하기도 했다.^[20]^[21] 하지만 현재는 미디어위키처럼 `링크할 페이지`와 같은 명시적인 문법을 사용하는 방식이 더 일반적이다.

4. 2. 위키

카멜 표기법은 일부 위키 마크업 언어에서 다른 위키 페이지를 자동으로 연결하는 데 사용되기도 한다. 이 방식은 워드 커닝햄이 만든 최초의 위키 소프트웨어인 WikiWikiWeb에서 처음 사용되었으며,^[40] 다른 여러 위키에서도 이 기능을 활성화할 수 있다.

TiddlyWiki, Trac, PmWiki와 같은 일부 위키 엔진은 기본적으로 카멜 표기법 링크를 사용하지만, 설정을 통해 비활성화하거나 관련 플러그인을 사용할 수도 있다.

위키백과도 과거에는 카멜 표기법 링크를 사용했으나, 현재는 대괄호를 이용한 명시적인 링크 방식을 사용하며,^[41] 많은 다른 위키 사이트들도 이 방식을 따르고 있다. 예를 들어, 위키백과의 기반 소프트웨어인 미디어위키는 카멜 표기법 링크를 지원하지 않는다.

하지만 카멜 표기법 링크를 사용하지 않는 위키에서도 여전히 페이지 이름 등에 카멜 표기법을 이름 지정 규칙으로 사용하는 경우(예: AboutUs)를 찾아볼 수 있다.

4. 3. 파일 이름

파일 시스템에서 파일 및 디렉터리(폴더)의 이름에 카멜 표기법이 사용되는 경우도 많다. 특히 명령줄 인터프리터로 파일 시스템을 조작할 때, 공백이 포함된 이름은 문제를 일으키는 경우가 많다. 이런 상황에서 카멜 표기법은 문자 수를 절약하면서도 가독성을 확보할 수 있다는 장점이 있다. 그러나 운영 체제 및 파일 시스템에 따라 대문자와 소문자가 동일하게 취급되거나, 모두 대문자로 처리되어 구별할 수 없는 환경도 있다는 점에 유의해야 한다.

4. 4. 마이크로블로깅 및 소셜 네트워크 서비스

메시지 글자 수 제한이 있는 마이크로블로깅이나 소셜 네트워크 서비스 (SNS) 등에서 카멜 표기법이 유용하게 쓰일 수 있다. 단어 사이에 카멜 표기법을 적용하면 띄어쓰기를 줄일 수 있어, 제한된 글자 수 안에 더 많은 내용을 담을 수 있기 때문이다.

특히 해시태그에서 카멜 표기법을 사용하면 가독성을 높이는 데 도움이 된다. 예를 들어, `#CollegeStudentProblems`와 같이 표기하면 `#collegestudentproblems`보다 내용을 파악하기 쉽다.^[42] 또한, 이러한 방식은 스크린 리더가 여러 단어가 합쳐진 해시태그를 인식하고 읽어주는 데 도움을 주어 접근성을 향상시키는 효과도 있다.^[43]

4. 5. 기타 용도

원래 캐멀 표기법은 복합어로 이루어진 인명에서도 찾아볼 수 있다. McDonald|맥도날드^영어 등은 한국어 사용자에게도 익숙한 예시 중 하나이다.

상품명이나 서비스명에서도 캐멀 표기법이 자주 사용된다. 플레이스테이션(PlayStation|플레이스테이션^영어), 아이폰(iPhone|아이폰^영어), 블랙베리(BlackBerry|블랙베리^영어), 원드라이브(OneDrive|원드라이브^영어), 유튜브(YouTube|유튜브^영어) 등이 대표적이다. 이렇게 하면 공백 없이 하나의 단어로 된 고유명사가 되어 웹 검색 엔진에서 쉽게 구분된다는 장점이 있다.

파일 시스템에서 파일이나 디렉터리(폴더) 이름을 정할 때 캐멀 표기법이 사용되기도 한다. 특히 명령줄 환경에서 파일 시스템을 다룰 때, 이름에 공백이 있으면 문제가 생길 수 있으므로, 문자 수를 줄이면서도 가독성을 높일 수 있는 캐멀 표기법은 유용하다. 하지만 사용하는 운영 체제나 파일 시스템에 따라 대소문자를 구분하지 않거나 모두 대문자로 처리하는 경우도 있어 주의가 필요하다.

초창기 위키에서는 캐멀 표기법으로 작성된 단어를 자동으로 하이퍼링크로 만드는 기능이 있었다. 그러나 현재는 미디어위키처럼 ``와 `` 기호를 사용하여 명시적으로 링크를 만드는 방식이 일반적이며, 캐멀 표기법을 이용한 링크 생성 방식은 잘 사용되지 않는다.

5. 가독성 논란

낙타 표기법은 단어 사이의 공백을 없애고 각 단어의 첫 글자를 대문자로 표기하는 방식 때문에 가독성을 해친다는 비판을 받기도 한다.^[44]

실제로 가독성에 대한 여러 연구가 진행되었다. 2009년에는 135명을 대상으로 스네이크 표기법(밑줄로 단어를 구분하는 방식)과 낙타 표기법을 비교하는 연구가 이루어졌다. 이 연구 결과, 실험 참가자들은 낙타 표기법으로 작성된 식별자를 더 정확하게 인식했지만, 스네이크 표기법으로 작성된 식별자를 더 빠르게 인식하는 경향을 보였다. 낙타 표기법에 대한 훈련이 인식 속도에 영향을 미치기는 했지만, 통계적으로 큰 의미는 없었다(p값이 높게 나타남). 또한, 프로그래밍 경험이 없는 사람들은 스네이크 표기법을 선호하거나 특별히 선호하는 방식이 없었으며, 낙타 표기법 훈련을 받은 프로그래머 중에서도 38%는 스네이크 표기법을 선호한다고 답했다. 하지만 이러한 개인적인 선호도는 실제 식별자를 읽는 정확도나 속도와는 통계적으로 관련이 없는 것으로 나타났다.^[45]

2010년에 진행된 후속 연구에서는 스네이크 표기법에 더 익숙한 전문 프로그래머 15명을 대상으로 비슷한 실험을 했다. 이 연구에서도 참가자들은 스네이크 표기법 식별자를 더 빠르게 인식했다. 시선 추적 장비를 이용한 분석 결과, 특히 세 단어로 이루어진 식별자의 경우 낙타 표기법을 볼 때 평균적인 주시 시간이 더 길었다는 점이 속도 차이의 원인으로 밝혀졌다. 이 연구에서도 참가자들의 선호하는 표기법은 다양하게 나타났지만, 선호도와 실제 작업 속도나 정확도 사이에는 유의미한 관계가 없었다.^[46]

가독성 외에 카멜 표기법의 또 다른 단점은 철자 오류를 자동으로 검사하는 스펠 체커 기능의 활용이 어렵다는 점이다. 마이크로소프트 워드와 같은 일반적인 워드 프로세서 프로그램은 널리 알려진 고유 명사를 제외하고는 카멜 표기법으로 작성된 단어를 철자 오류로 인식하는 경우가 많다. 물론 자연어 문장 속에서 카멜 표기법이 사용될 때는 공백이나 하이픈 누락 등 실제 오류일 가능성이 높기 때문에 이러한 작동 방식이 완전히 틀린 것은 아니다.

하지만 프로그래밍 코드 편집기 중에는 텍스트 편집기의 일종으로서, 주석이나 문자열 내부뿐만 아니라, 카멜 표기법으로 작성된 식별자의 철자까지 검사해주는 기능을 지원하는 경우도 있다.

6. 한국어권에서의 사용

한국어권에서도 캐멀 표기법은 상품명이나 서비스명 등에서 흔히 찾아볼 수 있다. 플레이스테이션(PlayStation), 아이폰(iPhone), 블랙베리(BlackBerry), 원드라이브(OneDrive), 유튜브(YouTube) 등이 대표적인 예시다. 이 표기법은 단어를 공백 없이 이어 하나의 고유 명사로 만들기 때문에, 웹 검색 엔진에서 해당 명칭을 쉽게 인식하고 검색 결과에 잘 반영할 수 있다는 장점이 있다.

참조

_[1] 서적 The Grammar Devotional: Daily Tips for Successful Writing from Grammar Girl https://books.google[...] St. Martin's Publishing Group 2009-10-27
_[2] 서적 Understanding and Teaching English Spelling: A Strategic Guide https://books.google[...] Routledge 2018-09-21
_[3] 서적 Dreyer's English: An Utterly Correct Guide to Clarity and Style https://books.google[...] Random House Publishing Group 2020-08-04
_[4] 웹사이트 Naming Conventions http://docs.scala-la[...] Scala 2012-12-05
_[5] 웹사이트 Capitalization Styles - .NET Framework 1.1 http://msdn.microsof[...] 2012-12-05
_[6] 웹사이트 Camel Case http://c2.com/cgi/wi[...] 2016-03-10
_[7] 웹사이트 Ada 95 Quality and Style Guide https://www.adaic.or[...] 2020-01-25
_[8] 웹사이트 C# Coding Standards and Guidelines http://www2.tech.pur[...]
_[9] 웹사이트 CamelCase@Everything2.com http://everything2.c[...] 2010-06-04
_[10] 웹사이트 Style Guide for Python Code http://legacy.python[...]
_[11] 뉴스그룹 compoundNames https://groups.googl[...] 1990-03-29
_[12] 웹사이트 '[#APF-1088] If class name has embedded capitals, AppGen code fails UI tests and generated hyperlinks are incorrect. – AppFuse JIRA' http://issues.appfus[...] 2010-06-04
_[13] 웹사이트 ASP Naming Conventions http://www.shiningst[...] Nannette Thacker 1999-05-01
_[14] 서적 AMA Manual of Style https://archive.org/[...] Oxford University Press
_[15] 웹사이트 The Brief New Century Handbook – Rules for internal capitalization http://wps.ablongman[...] Pearson Education
_[16] 웹사이트 What is the name for a word containing two capital letters (like WordPad)? http://www.askoxford[...] Internet Archive 2022-06-12
_[17] 웹사이트 Brad Abrams: History around Pascal Casing and Camel Casing https://learn.micros[...] 2024-10-21
_[18] 웹사이트 Pascal Case http://c2.com/cgi/wi[...] 2014-01-04
_[19] 웹사이트 NET Framework General Reference Capitalization Styles http://msdn2.microso[...] 2014-01-04
_[20] 웹사이트 WikiWord http://twiki.org/cgi[...] 2010-06-04
_[21] 웹사이트 Wiki Case http://c2.com/cgi/wi[...] 2010-06-04
_[22] 뉴스그룹 compoundNames https://groups.googl[...] 1990-04-03
_[23] 웹사이트 I'm happy again! – comp.os.os2.advocacy | Google Groups http://groups.google[...] 2009-05-23
_[24] 웹사이트 Newton Love http://sluug.org/~ne[...]
_[25] 서적 "Richtiges und gutes Deutsch: Das Wörterbuch der sprachlichen Zweifelsfälle" Bibliographisches Institut 2011
_[26] 서적 The King's English http://www.bartleby.[...] Oxford University Press 2009-12-19
_[27] 문서 Jöns Jacob Berzelius
_[28] 서적 Henry M. Leicester
_[29] 서적 The Trade-mark Reporter United States Trademark Association
_[30] 웹사이트 Mister Rogers Neighborhood Season 1 (Episode 4) https://archive.org/[...] 2022-06-21
_[31] 웹사이트 Our History http://www.unitedhea[...] 2019-05-15
_[32] 웹사이트 '"Resume of Session 8". Digital Computers: Advanced Coding Techniques. Summer Session 1954, Massachusetts Institute of Technology' http://www.bitsavers[...] 2014-01-04
_[33] 간행물 A General Purpose Macrogenerator 1965-10
_[34] 서적 Proceedings of the third ACM SIGPLAN conference on History of programming languages
_[35] 웹사이트 Declare variables - Training https://learn.micros[...] 2023-08-29
_[36] 뉴스 Grads Want to Study on EMacs, Too https://www.wired.co[...] 2002-04-30
_[37] 간행물 'Feedback, 20 June 1998' https://www.newscien[...] New Scientist 1998-06-20
_[38] 웹사이트 Google Java Style Guide https://google.githu[...] 2022-11-02
_[39] 논문 To CamelCase or Under_score IEEE
_[40] 서적 The Wikipedia Revolution: How a Bunch of Nobodies Created the World's Greatest Encyclopedia Hyperion
_[41] 서적 The Wikipedia Revolution
_[42] 웹사이트 Accessible Use of CamelCase and Structuring Posts https://ecampusontar[...]
_[43] 웹사이트 Social Media Accessibility Guidelines https://accessibilit[...] 2022-10-12
_[44] 뉴스 Against Camel Case https://www.nytimes.[...] 2009-11-23
_[45] 논문 To CamelCase or Under_score IEEE
_[46] 서적 2010 IEEE 18th International Conference on Program Comprehension IEEE
_[47] 웹사이트 キャメルケースとは - 意味をわかりやすく - IT用語辞典 e-Words https://e-words.jp/w[...]
_[48] 웹사이트 Capitalization Conventions - Framework Design Guidelines | Microsoft Learn https://learn.micros[...]
_[49] 서적 Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries Addison-Wesley Professional 2008-10-22
_[50] 서적 .NETのクラスライブラリ設計日経BP 2009-12-28
_[51] 문서 bi-capitalization
_[52] 문서 intercaps
_[53] 문서 mixed-case
_[54] 문서 upper camel case
_[55] 문서 lower camel case
_[56] 웹사이트 Java／.NET開発者のための「ここが変だよ、COBOL」：COBOL - Getting Started（1）（2/2 ページ） - ＠IT https://atmarkit.itm[...]
_[57] 웹사이트 古いコンピュータやOSで小文字ではなく大文字が使用されていた理由とは？ - GIGAZINE https://gigazine.net[...]
_[58] 웹사이트 C Identifiers | Microsoft Learn https://learn.micros[...]
_[59] 웹사이트 Stroustrup: C++ Style and Technique FAQ https://www.stroustr[...]
_[60] 웹사이트 Stroustrup: C++ Style and Technique FAQ 日本語訳 http://www.libjingu.[...]
_[61] 웹사이트 Code Conventions for the Java Programming Language: 9. Naming Conventions https://www.oracle.c[...]
_[62] 웹사이트 Pascal ISO/IEC 7185:1990 https://www.cs.utexa[...]
_[63] 웹사이트 WriteLn | Free Pascal https://www.freepasc[...]
_[64] 웹사이트 WriteLn - The GNU Pascal Manual https://www.gnu-pasc[...]
_[65] 문서 PHP言語の関数
_[66] 문서 標準C++ライブラリに含まれるクラステンプレート
_[67] 문서 Windows PowerShellのコマンド
_[68] 문서 Scheme言語の組み込み関数
_[69] 웹사이트 Learn about the Spell Checker - Visual Studio (Windows) | Microsoft Learn https://learn.micros[...]

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com