카멜 케이스

Camel case
낙타 케이스는 일반적인 낙타의 혹과 비슷하게 튀어나온 대문자의 "엉덩이"에서 이름을 따왔다.

카멜 케이스(camel Case 또는 Camel Case라고도 하며, 카멜 캡이라고도 하며, 더 형식적으로 중앙 대문자라고도 함)는 공백이나 구두점을 사용하지 않고 구문을 쓰는 관행입니다.대문자 한 글자로 단어를 구분하고 첫 단어는 대소문자로 시작합니다.일반적인 예로는 "iPhone"과 "eBay"가 있습니다.또한 "johnSmith"와 같은 온라인 사용자 이름이나 "EasyWidgetCompany.com" 홍보와 같이 다중 단어 도메인 이름을 읽기 쉽게 만들기 위해 사용되기도 합니다.

카멜 대소문자는 컴퓨터 프로그래밍에서 명명규칙으로 자주 사용되지만 첫 번째 문자의 대문자 선택으로 인해 애매한 정의입니다.일부 프로그래밍 스타일은 첫 글자가 대문자로 표시된 카멜 케이스를 선호하지만 다른 스타일은 그렇지 않습니다.[1][2][3]이 문서에서는 두 가지 대안을 대문자 대문자(Pascal 대문자 또는 울퉁불퉁 대문자라고도 함)와 대문자 소문자 대문자(초기 소문자, 단봉대문자라고도 함)라고 부릅니다.일부 개인 및 조직, 특히 마이크로소프트는 카멜 케이스라는 용어를 하의 카멜 케이스에만 사용하고 있으며, 파스칼 케이스는 상위의 카멜 [2]케이스에 해당합니다.

카멜 대소문자는 모든 단어를 대문자로 사용하면서도 공백은 유지한 제목 대소문자, "프레드니소네"와 "프레드니솔론"과 같은 유사한 제품 이름의 차이를 강조하기 위해 대소문자를 사용하는 톨맨 문자와는 다릅니다.카멜 대소문자는 소문자(경우에 따라 첫 글자가 대문자로 표시됨)로 구분되는 스네이크 대소문자와도 다릅니다.snake와 camel case의 조합(식별자 기입_)Like_This)는 Ada 95 스타일 [4]가이드에서 권장됩니다.

변형 및 동의어

프랙티스에는 다음과 같은 다양한 이름이 있습니다.

Usenet에서 "InterCaps"라는 용어가 처음 알려진 것은 Avi Rapport가 [19]1990년 4월에 그룹에 게시한 글입니다."Camel Case"라는 이름의 최초 사용은 1995년 뉴턴 [20]러브가 게시한 글에서 비롯되었다.Love는 그 후 다음과 같이 말했습니다. "이러한 구조를 가진 프로그래밍 언어가 등장함에 따라 CamelCase를 선택하기 전에 처음에는 HumpyCase라고 불렀습니다.몇 년 전부터 카멜케이스라고 불렀는데...위의 인용문은 USENET에서 [21]이 이름을 처음 사용한 것입니다.

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

단어 조합

일상 텍스트의 규칙적인 철자법에서 중간 대문자 사용은 드물지만, 일부 언어에서는 두 단어 또는 세그먼트가 결합되었을 때 발생하는 특정 문제에 대한 해결책으로 사용됩니다.

이탈리아어에서 대명사는 동사에 붙일 수 있고, 2인칭 대명사의 존댓말은 대문자로 표기되기 때문에, 이것은 non trovato il temp di risponderLe("나는 너에게 대답할 시간을 찾지 못했다")와 같은 문장을 만들 수 있다.

독일어로 빈넨 I라고 불리는 중간 대문자 I는 때때로 Student와 같은 단어로 사용된다.Innen("학생")은 Studenten("남학생")과 Studentinen("여학생")이 동시에 의도된 것임을 나타냅니다.그러나 중간어 대문자는 맥도날드와 같은 고유 이름을 제외하고는 독일어 맞춤법에 부합하지 않는다. 앞의 예는 영어의 [22]"의회(wo)"와 유사하게 Student(inn)en으로 괄호를 사용하여 올바르게 표기할 수 있다.

아일랜드어에서 카멜 케이스는 고유명사, 예를 들어 가일림(Gaillimh), 스코틀랜드인(Albanach), 스코틀랜드인(Albanach), 아일랜드인(Ireland)의 고하이린(Geirin)에 굴절 접두사가 붙을 때 사용된다.최근 스코틀랜드 게일어 철자법에서는 하이픈인 t-Albannach가 삽입되었다.

이 규약은 또한 몇몇 문자 반투어(isiZulu, "줄루어" 등)와 멕시코의 몇몇 토착 언어(예: 나후아틀어, 토토나칸어, 믹스-조케어 및 일부 오토망게어)에서도 사용된다.

네덜란드어에서는 ij를 대문자로 할 때 I와 J를 대문자로 쓴다(예: 국가명 IJsland("아이슬란드")

중국 병음에서는 때때로 낙타 케이스를 지명으로 사용하여 독자들이 이름의 다른 부분을 더 쉽게 찾을 수 있도록 한다.예를 들어 베이징(北京), 친황다오(秦黃島), 대싱안링(大興安 () 등은 각각 베이징(北京), 친황다오(秦黃島), 대싱안링(大興安 respect)으로 표기할 수 있으며 대문자 수는 한자 수와 같다.각 글자의 첫 글자로만 단어 합성어를 쓰는 것도 허용되기 때문에 베이징은 BJ, 칭황다오는 QHD, 대싱안링은 DXAL로 표기할 수 있다.

영어에서 중간 대문자(medial capaces)는 일반적으로 스코틀랜드 또는 아일랜드어 "Mac-" 또는 "Mc-"에서만 볼 수 있습니다. 예를 들어 맥도날드, 맥도날드 및 맥도날드는 같은 이름의 일반적인 철자 변형이며, 영국-노르만 "Fitz-" 및 피츠제럴드 모두 볼 수 있습니다.

1906년에 처음 출판된 영국식 안내서 The King's English에서 H. W.와 F. G. Fowler는 중간 대소문자를 하이픈이 모호함을 야기할 수 있는 세 개의 복합어로 사용할 수 있다고 제안했습니다 - 그들이 제시하는 예는 킹 마크와 같은 (영국-남미에 대한)와 앵글로-남미입니다.그러나 그들은 이 시스템을 [23]"현재로서는 너무 절망적으로 반대"라고 묘사했다.

번역 시

다른 문자로 쓰여진 언어의 학술적 번역에서는, 중간 대문자(medial capital)가 비슷한 상황에서 사용됩니다.예를 들어, 히브리어로 하이브리는 "히브리인" 또는 "유대인"을 의미하고, 브예루샬라임은 "예루살렘에"를 의미합니다.rLobsang과 같은 티베트 고유 이름에서, "r"은 원래의 문자에서 일반적인 문자가 아닌 음조 표시로 기능하는 접두사 글리프를 나타냅니다.또 다른 예로는 체첸어를 라틴어로 번역한 tsIurku가 있는데, 이는 중세 특유의 체첸과 잉구셰티아의 방어탑의 덮개돌을 뜻한다. "I" (팔로치카)는 "i"로 번역된 것과 구별되는 음소를 나타내는, 실제로는 대문자 "I"가 아니다.

약어

중간 대문자(medial capaces)는 전통적으로 PhD 또는 BSc와 같이 단어들이 완전히 쓰여질 때 대문자화를 반영하기 위해 약자로 사용됩니다.보다 최근의 예로는 NaNoWriMo가 있습니다.NaNoWriMo는 National Novel Writing Month를 축약한 것으로 연례 행사와 이를 운영하는 비영리 단체 모두에 대한 지정입니다.독일어로 법령명은 StGB for Strafgesetzbuch(형법), PatG for Pertentgesetz(특허법), BVerfG for Bundesfassungsgericht(연방헌법소) 또는 GHMBese 등 삽입 대문자를 사용하여 약칭한다.이러한 맥락에서, TzBfG(Teilzeit-and Befgesetz, 파트 타임 및 기간 한정 직업에 관한 법률)에는 3개 이상의 카멜 케이스 대문자(camel case capital)가 있을 수 있다.프랑스어에서는 OuLiPo(1960)와 같은 약자가 이니셜리즘의 대안으로 한동안 선호되었다.

카멜 대소문자는 알파벳으로 번역할 때 자주 사용됩니다.원래 알파벳의 단일 문자를 나타내기 위해 두 글자가 필요할 수 있습니다.예를 들어 키릴 문자 д cy cy cy cy cy cy cy cy cy cy cy cy cy cy cy cy cy cy cy cy cy cy 。

근대 기술 사용의 역사

화학식

기술적 목적을 위해 중앙 자본을 체계적이고 널리 사용한 최초의 것은 1813년 스웨덴의 화학자 야콥 베르젤리우스에 의해 발명된 화학 공식의 표기법이었다.그 때까지 화학자들이 사용했던 다수의 명명 및 기호 규칙을 대체하기 위해, 그는 각 화학 원소를 한두 글자의 기호(첫 번째 글자는 대문자로 표기)로 나타낼 것을 제안했다.대문자화를 통해 "NaCl"과 같은 공식은 공백 없이 쓰여지고 [24][25]모호함 없이 구문 분석될 수 있습니다.

베르젤리우스의 시스템은 확인되지 않거나 알려지지 않은 원소에 대해서는 "Uue"와 같은 세 글자의 기호와 몇몇 일반적인 대체물(특히 유기 화학 분야에서 "Et"는 "에틸-"을 의미한다)의 약자로 계속해서 사용되고 있다.이것은 단백질과 다른 유사한 도메인의 아미노산 서열을 설명하기 위해 더욱 확장되었다.

상표에서의 조기 사용

20세기 초반부터 중간 대문자(medial capital)가 기업명 및 제품 상표에 사용되는 경우가 있습니다.

  • DryIce Corporation(1925년)은 고체 형태의 이산화탄소2(CO)를 "드라이 아이스"로 마케팅하여 일반 [26]명칭으로 만들었다.
  • Cinema Scope 및 Vista Vision, 경쟁 와이드 스크린 무비 형식(1953)
  • ShopKo(1962), 소매점, 나중에 Shopko로 개명
  • 미스터 로저스 동네(1968년)[27]라고도 불리는 TV 시리즈 '미스터 로저스 동네'
  • ChemGrass(1965년), 나중에 AstroTurf(1967년)로 개명
  • ConAgra(1971년), 이전 통합 밀스
  • 스포츠 보트 제조사 마스터크래프트(1968년)
  • AeroVironment(1971년)
  • PolyGram(1972년), 구 Grammophon-Philips 그룹
  • United HealthCare (1977년)[28]
  • MasterCard(1979년), 이전 Master Charge
  • 스포츠 센터(1979년)

컴퓨터 프로그래밍

1970년대와 1980년대에는 여러 프로그래밍 언어에서 다중 단어 식별자를 위한 표준 또는 대체 명명 규칙으로 중간 대문자(medial capaces)가 채택되었다.컴퓨터 프로그래밍에서 그 규칙의 정확한 기원은 아직 정해지지 않았다.1954년 회의 절차에서는[29] IBM의 Speedcoding 시스템을 "SpeedCo"라고 비공식적으로 언급하기도 했습니다.크리스토퍼 스트레이시의 GPM(1965년)[30]에 관한 논문은 다음과 같은 중간 대문자 식별자를 포함하는 프로그램을 보여준다.NextCh" 및 "WriteSymbol".

다음과 같은 공백이 포함된 여러 단어 설명 식별자end of file또는char table단어 사이의 공백이 토큰 사이의 구분자로 구문 분석되기 때문에 대부분의 프로그래밍 언어에서는 사용할 수 없습니다.에서와 같이 단어를 함께 실행하는 대체 방법endoffile또는chartable이해하기 어렵고 오해를 일으킬 수 있습니다.예를 들어 다음과 같습니다.chartable는 영어 단어(그래프 작성 가능)인데 반해,charTable의 표를 의미한다.chars.

일부 초기 프로그래밍 언어들, 특히 Lisp (1958)와 COBOL (1959)은 "END-OF-FILE"에서처럼 복합 식별자의 단어 사이에 하이픈("-")을 사용하도록 허용함으로써 이 문제를 해결했다: Lisp는 프리픽스 표기법에서 잘 작동했기 때문이다(Lisp 파서는 BECO와 뺄셈 연산자로서 기호 중간에 있는 하이픈을 처리하지 않을 것이다).연산자는 개별 영어 단어였다.이 규칙은 이러한 언어에서 계속 사용되며 Unix와 같이 명령줄에 입력된 프로그램 이름에서도 일반적입니다.

그러나, 이 해법은 하이픈을 인픽스 감산 연산자로 사용한 FORTRAN(1955)과 ALGOL(1958)과 같은 수학 지향 언어에 적합하지 않았다.FORTRAN은 빈칸을 모두 무시했기 때문에 프로그래머들은 변수 이름에 내장된 공간을 사용할 수 있었다.그러나 이전 버전의 언어에서는 식별자가 6자 이내로 제한되었기 때문에 이 기능은 그다지 유용하지 않았습니다.

문제를 악화시키는 것은 당시 일반적인 펀치 카드 문자 집합이 대문자일 뿐 다른 특수 문자는 없었다는 것입니다.ASCII 문자 집합이 널리 채택되면서 소문자와 밑줄 문자가 모두 만들어진 것은 1960년대 후반입니다._보편적으로 이용 가능합니다.일부 언어(특히 C)는 단어 구분 기호 및 다음과 같은 식별자로 즉시 밑줄을 채택했습니다.end_of_fileC 프로그램 및 라이브러리(Perl 및 Python과 같은 C의 영향을 받은 이후 언어)에서 여전히 널리 사용되고 있습니다.그러나 일부 언어와 프로그래머는 공백과 혼동하지 않기 위해 밑줄을 피하는 대신 카멜 케이스를 채택했습니다.

1970년대에 Xerox PARC에서 근무한 Charles Simonyi는 Microsoft Office 어플리케이션 스위트 작성을 감독했으며 헝가리 표기법 사용법을 발명하여 가르쳤습니다. 헝가리 표기법 중 하나는 (대문자로 된) 변수 이름의 선두에 소문자를 사용하여 유형을 나타냅니다.한 설명에 따르면[citation needed] 카멜 케이스 스타일은 1978년경 Xerox PARC에서 처음 인기를 끌었으며, Mesa 프로그래밍 언어는 Xerox Alto 컴퓨터용으로 개발되었다.이 컴퓨터에는 밑줄 키가 없습니다(왼쪽 화살표 "←"로 표시됨). 식별자에 하이픈과 공백 문자를 사용할 수 없으므로 카멜 대소문자를 읽을 수 있는 다중 단어 이름에 사용할 수 있는 유일한 체계로 남았습니다.PARC Mesa Language Manual(1979)에는 Mesa 라이브러리와 Alto 운영체제에 의해 엄격하게 준수된 상위 및 하위 캐멀 케이스에 대한 특정 규칙이 포함된 코딩 표준이 포함되어 있습니다.파스칼의 발명가인 니클라우스 워스는 PARC에서 안식년을 보내는 동안 낙타 케이스를 감상하게 되었고 그의 다음 프로그래밍 [31]언어인 Modula에서 그것을 사용했다.

원래 Alto에서 개발된 Smalltalk 언어 또한 밑줄 대신 카멜 케이스를 사용한다.이 언어는 1980년대 초에 꽤 대중화되었고, 따라서 PARC 바깥으로 스타일을 확산시키는 데에도 중요한 역할을 했을 수 있다.

상부 카멜 대문자(또는 "Pascal 대문자")는 컴퓨터 대수 시스템 매스매티카의 울프람 언어로 사전 정의된 식별자를 위해 사용됩니다.사용자 정의 식별자는 소문자로 시작해야 합니다.이를 통해 현재 및 향후 모든 버전에서 사전 정의된 식별자와 사용자 정의 식별자 간의 충돌을 방지할 수 있습니다.

컴퓨터 회사 및 제품

컴퓨팅 분야에서 유래가 무엇이든 간에 이 컨벤션은 1970년대 후반부터 컴퓨터 회사와 그 상업용 브랜드의 이름으로 사용되었습니다.이 경향은 오늘날까지 계속되고 있습니다.

주류 사용으로 확산

1980년대와 1990년대 PC의 출현으로 해커 문화가 세상에 알려지면서 카멜 케이스는 컴퓨터 이외의 분야에서도 기업 상호에 유행하게 되었다.1990년에는 주류 사용이 잘 확립되었습니다.

1990년대 후반 닷컴 버블 동안 소문자 접두사 "e"(전자)와 "i"(인터넷,[32] 정보, 인텔리전트 등)가 상당히 보편화되면서 애플의 iMac과 eBox 소프트웨어 플랫폼과 같은 이름이 생겨났다.

1998년 Dave Yost는 화학자들이 긴 화학명의 가독성을 돕기 위해 중간 대문자(예: Amidophosphoribosyl Transferase)[33]를 사용할 것을 제안했다.이 용법은 널리 채택되지 않았다.

카멜 케이스는 특정 지역의 약칭에 사용되기도 합니다.뉴욕시 인근 SoHo(휴스턴 거리 남쪽)와 TriBeca(운하 거리 아래쪽 트라이앵글) 및 San Francisco SoMa(시장 남쪽)입니다.이러한 관습은 빠르게 침식되기 때문에, 현재는 일반적으로 소호, 트리베카, 소마로 표현된다.

내부 대문자는 Hela(1983)와 같은 다른 기술 코드에도 사용되고 있습니다.

컴퓨팅의 현재 사용 현황

프로그래밍 및 코딩

주요 기사:명명 규칙(프로그래밍)

많은 조직 또는 소프트웨어 프로젝트의 코딩 스타일 지침에 따라 복합 식별자에 중간 캡을 사용할 것을 권장합니다.일부 언어(Mesa, Pascal, Modula, Java 및 Microsoft 등)의 경우NET) 이 프랙티스는 언어 개발자나 권위 있는 매뉴얼에 의해 권장되고 있기 때문에 언어 "문화"의 일부가 되었습니다.

스타일 가이드라인은 종종 상부와 하부를 구분하며, 일반적으로 변수, 레코드 필드, 메서드, 프로시저, 함수, 서브루틴, 유형 등 특정 유형의 엔티티에 사용해야 하는 품종을 지정합니다.이러한 규칙은 소스 코드의 준수를 검사하는 정적 분석 도구에 의해 지원되는 경우가 있습니다.

예를 들어, 프로그래밍의 원래 헝가리 표기법은 "사용 유형"의 소문자 약자(데이터 유형이 아님)는 모든 변수 이름 앞에 접두사를 붙여야 하며 이름의 나머지 부분은 대문자 카멜 대문자여야 합니다. 따라서 하위 카멜 대문자 형식입니다.

프로그래밍 식별자에는 "old HTML file"과 같이 이미 대문자로 되어 있는 머리글자어와 이니셜이 포함되어 있어야 하는 경우가 많습니다.타이틀 케이스 규칙과 유사하게, 내추럴 카멜 케이스 렌더링에서는 모두 대문자로 줄임말을 사용합니다.즉, "old"HTMLFile"을 클릭합니다.단, 이 접근법은 두 개의 두 개의 두문자어가 동시에 발생하는 경우(예를 들어 "parse DBM XML"이 "parse DBMXML"이 됨) 또는 표준에서 소문자를 요구하지만 이름이 약자로 시작하는 경우(예를 들어 "SQL server"가 "SQ"가 됨)에는 문제가 있습니다.LServer').이러한 이유로 일부 프로그래머는 약어를 소문자로 취급하여 "oldHtmlFile", "parseDbmXml" 또는 "sqlServer"를 쓰는 것을 선호합니다.그러나 이는 주어진 단어가 [34]약자로 의도된 것임을 인식하기 어렵게 할 수 있다.

Wiki 링크 마크업

카멜 대소문자는 일부 위키 마크업 언어에서 다른 위키 페이지에 자동으로 연결되어야 하는 용어로 사용됩니다.이 규칙은 원래 Ward Cunningham의 원래 WikiWikiWeb에서 사용되었으며 대부분의 다른 Wiki에서 활성화할 수 있습니다.TiddlyWiki, Trac 및 PmWiki와 같은 일부 Wiki 엔진에서는 기본 설정으로 이를 사용하지만 일반적으로 이를 비활성화하는 구성 메커니즘 또는 플러그인도 제공합니다.Wikipedia에서도 이전에는 camel case linking을 사용했지만, 각괄호를 사용한 명시적인 link markup으로 전환하여 다른 많은 위키 사이트들도 동일한 작업을 수행해왔다.예를 들어 MediaWiki는 링크에 대한 camel 케이스를 지원하지 않습니다.카멜 대소문자 링크를 사용하지 않는 일부 Wiki에서는 AboutUs와 같이 카멜 대소문자를 명명 규칙으로 사용할 수 있습니다.

기타 용도

NIEM 레지스트리에서는 XML 데이터 요소는 대문자와 소문자를 사용하고 XML 속성은 소문자를 사용해야 합니다.

대부분의 일반적인 명령줄 인터페이스 및 스크립트 언어에서는 삽입 공간이 포함된 파일 이름을 쉽게 처리할 수 없습니다(보통 따옴표로 이름을 묶어야 함).따라서 이러한 시스템의 사용자는 MyJobResume.pdf와 같은 복합 파일 이름에서 종종 캐멀 대문자(또는 밑줄, 하이픈 및 기타 "안전한" 문자)를 사용합니다.

마이크로블로그와 메시지의 글자 수를 제한하는 소셜 네트워킹 서비스는 미디어 캐피털의 잠재적 배출구이다.단어 사이에 camel 대소문자를 사용하면 주어진 메시지에서 공백의 수가 줄어들고 제한된 공간에 더 많은 콘텐츠를 넣을 수 있습니다.해시태그, 특히 긴 해시태그는 가독성을 유지하기 위해 종종 카멜 대소문자를 사용합니다(예: #CollegeStudentProblems는 #collegestudentProblems보다 읽기 쉽습니다).

웹 사이트 URL에서 공백이 %20으로 백분율로 인코딩되어 주소가 길고 사람이 읽을 수 없습니다.공백이 생략되어 있기 때문에 카멜 케이스는 이 문제가 없습니다.

가독성 조사

카멜 케이스는 공백 제거와 모든 [35]단어의 대문자로 인해 가독성에 부정적인 영향을 미친다는 비판을 받아왔다.

2009년 스네이크 케이스와 카멜 케이스를 비교한 연구에서는 프로그래머와 비프로그래머 모두에서 더 높은 정확도로 카멜 케이스 식별자를 인식할 수 있었고, 이미 카멜 케이스에 대해 훈련받은 프로그래머는 밑줄 친 뱀 케이스 [36]식별자보다 더 빨리 그러한 식별자를 인식할 수 있었다.

주로 사전 훈련을 받은 프로그래머를 포함하고 아이 트래킹 장비를 사용하여 개선된 측정 방법을 사용한 2010년 후속 연구는 다음과 같습니다. "결과에 따르면 두 스타일의 정확도에 차이가 없지만 피실험자는 언더스코어 스타일의 식별자를 더 [37]빨리 인식합니다."

「 」를 참조해 주세요.

레퍼런스

  1. ^ "Naming Conventions". Scala. Retrieved 5 December 2012.
  2. ^ a b "Capitalization Styles - .NET Framework 1.1". Retrieved 5 December 2012.
  3. ^ "Camel Case". Retrieved 10 March 2016.
  4. ^ "Ada 95 Quality and Style Guide". October 1995. Section 3.1.3. Retrieved 25 January 2020.
  5. ^ C# 코딩 표준 및 가이드라인 2008년 4월 11일 Purdue University College of Technology Wayback Machine에서 아카이브
  6. ^ "[email protected]". Everything2.com. Retrieved 4 June 2010.
  7. ^ a b www.python.org에 있는 Python 코드 스타일 가이드
  8. ^ Feldman, Ian (29 March 1990). "compoundNames". Newsgroup: alt.folklore.computers. Usenet: [email protected].
  9. ^ "[#APF-1088] If class name has embedded capitals, AppGen code fails UI tests and generated hyperlinks are incorrect. – AppFuse JIRA". Issues.appfuse.org. Archived from the original on 25 June 2017. Retrieved 4 June 2010.
  10. ^ ASP 명명 규칙 2009년 4월 8일 Wayback Machine에서 Nannette Thacker에 의해 아카이브됨(1999년 5월 01일)
  11. ^ Iverson, Cheryl; Christiansen, Stacy; Flanagin, Annette; Fontanarosa, Phil B.; Glass, Richard M.; Gregoline, Brenda; Lurie, Stephen J.; Meyer, Harriet S.; Winker, Margaret A.; Young, Rozanne K., eds. (2007). AMA Manual of Style (10th ed.). Oxford, Oxfordshire: Oxford University Press. ISBN 978-0-19-517633-9.
  12. ^ Hult, Christine A.; Huckin, Thomas N. "The Brief New Century Handbook – Rules for internal capitalization". Pearson Education. Archived from the original on 7 April 2012.
  13. ^ "What is the name for a word containing two capital letters (like WordPad)?". AskOxford. Internet Archive. Archived from the original on 25 October 2008. Retrieved 12 June 2022.{{cite web}}: CS1 maint: bot: 원래 URL 상태를 알 수 없습니다(링크).
  14. ^ "Brad Abrams: History around Pascal Casing and Camel Casing". Blogs.msdn.com. 3 February 2004. Retrieved 4 January 2014.
  15. ^ "Pascal Case". C2.com. 27 September 2012. Retrieved 4 January 2014.
  16. ^ "NET Framework General Reference Capitalization Styles". MSDN2.microsoft.com. Retrieved 4 January 2014.
  17. ^ "WikiWord". Twiki.org. Retrieved 4 June 2010.
  18. ^ "Wiki Case". C2.com. 8 February 2010. Retrieved 4 June 2010.
  19. ^ Rappoport, Avi (3 April 1990). "compoundNames". Newsgroup: alt.folklore.computers.
  20. ^ Newton Love (12 September 1995). "I'm happy again! – comp.os.os2.advocacy Google Groups". Groups.google.com. Retrieved 23 May 2009.
  21. ^ 뉴턴 러브[데드링크]
  22. ^ Richtiges und gutes Deutsch: Das Wörterbuch der sprachlichen Zweifelsfälle. Duden (in German). Vol. 9 (7th ed.). Mannheim: Bibliographisches Institut. 2011. p. 418. ISBN 978-3411040971.
  23. ^ Fowler, Henry W.; Fowler, Francis G. (1908). "Chapter IV. Punctuation – Hyphens". The King's English (2nd ed.). Oxford. Archived from the original on 31 December 2009. Retrieved 19 December 2009.
  24. ^ 옌스 야콥 베르젤리우스(1813).화학적 비율의 원인과 그에 관한 몇 가지 상황에 대한 에세이: 짧고 쉬운 표현 방법과 함께.철학연보 2, 443-454, 3, 51-52; (1814) 93-106, 244-255, 353-364.
  25. ^ 헨리 M.Leister & Herbert S. Klikstein, eds. 1952, A Source Book in Chemistry, 1400~1900 (캠브리지, 매사추세츠: 하버드)
  26. ^ The Trade-mark Reporter. United States Trademark Association. 1930. ISBN 1-59888-091-8.
  27. ^ "Mister Rogers Neighborhood Season 1 (Episode 4)". Retrieved 21 June 2022.
  28. ^ "Our History". unitedhealthgroup.com. Retrieved 15 May 2019.[영구 데드링크]
  29. ^ ""Resume of Session 8". Digital Computers: Advanced Coding Techniques. Summer Session 1954, Massachusetts Institute of Technology" (PDF). 1954. pp. 8–6. Archived from the original (PDF) on 29 February 2012. Retrieved 4 January 2014.
  30. ^ Strachey, Christopher (October 1965). "A General Purpose Macrogenerator". Computer Journal. 8 (3): 225–241. doi:10.1093/comjnl/8.3.225.
  31. ^ Niklaus Wirth (2007). "Modula-2 and Oberon". Proc. 3rd Conf. History of Programming Languages. Hopl III. San Diego: 3-1–3-10. CiteSeerX 10.1.1.91.1447. doi:10.1145/1238844.1238847. ISBN 9781595937667. S2CID 1918928.
  32. ^ Farhad Manjoo (30 April 2002). "Grads Want to Study on EMacs, Too". Wired.com. Retrieved 4 June 2010.
  33. ^ 피드백, 1998년 6월 20일 제158권 No 2139 1998년 6월 20일
  34. ^ Dave Binkley; Marcia Davis; Dawn Lawrie; Christopher Morrell (2009). "To CamelCase or Under_score". IEEE 17th International Conference on Program Comprehension, 2009. ICPC '09. IEEE: 158–167. CiteSeerX 10.1.1.158.9499. In terms of camel-cased identifiers, this has a greater impact on identifiers that include short words and especially acronyms. For example, consider the acronym ID found in the identifier kIOuterIIDPath. Because of the run of uppercase letters, the task of reading kIOuterIIDPath, in particular the identification of the word ID, is more difficult.
  35. ^ Caleb Crain (23 November 2009). "Against Camel Case". New York Times.
  36. ^ Dave Binkley; Marcia Davis; Dawn Lawrie; Christopher Morrell (2009). "To CamelCase or Under_score". IEEE 17th International Conference on Program Comprehension, 2009. ICPC '09. IEEE: 158–167. CiteSeerX 10.1.1.158.9499. The experiment builds on past work of others who study how readers of natural language perform such tasks. Results indicate that camel casing leads to higher accuracy among all subjects regardless of training, and those trained in camel casing are able to recognize identifiers in the camel case style faster than identifiers in the underscore style.
  37. ^ Bonita Sharif; Jonathan I. Maletic (2010). "An Eye Tracking Study on camelCase and under_score Identifier Styles". IEEE 18th International Conference on Program Comprehension, 20010. ICPC '10. IEEE: 196–205. CiteSeerX 10.1.1.421.6137. doi:10.1109/ICPC.2010.41. ISBN 978-1-4244-7604-6. S2CID 14170019. (download PDF). An empirical study to determine if identifier-naming conventions (i.e., camelCase and under_score) affect code comprehension is presented. An eye tracker is used to capture quantitative data from human subjects during an experiment. The intent of this study is to replicate a previous study published at ICPC 2009 (Binkley et al.) that used a timed response test method to acquire data. The use of eye-tracking equipment gives additional insight and overcomes some limitations of traditional data gathering techniques. Similarities and differences between the two studies are discussed. One main difference is that subjects were trained mainly in the underscore style and were all programmers. While results indicate no difference in accuracy between the two styles, subjects recognize identifiers in the underscore style more quickly.

외부 링크

Wikimedia Commons에는 Camel 케이스와 관련된 미디어가 있습니다.
무료 사전인 위키사전에서 낙타 케이스를 찾아보세요.