CamelCase에 대한 의문이 있습니다. 이 약어가 있다고 가정하십시오.Unesco = United Nations Educational, Scientific and Cultural Organization.

당신은 작성해야합니다 : unitedNationsEducationalScientificAndCulturalOrganization

그러나 약어를 쓰려면 어떻게해야합니까? 다음과 같은 것 :

getUnescoProperties();

이런 식으로 쓰는 것이 옳습니까? getUnescoProperties() OR getUNESCOProperties();

Microsoft가 작성한 일부 지침camelCase 은 다음과 같습니다.

두문자어 이상의 약어는 파스칼 대소 문자 나 낙타 대소 문자를 사용하십시오. 예를 들어 HtmlButton또는을 사용하십시오 htmlButton. 그러나, 당신은 다음과 같은 두 개의 문자로 구성 약어, 활용해야한다 System.IO대신을 System.Io.

식별자 또는 매개 변수 이름에 약어를 사용하지 마십시오. 약어를 사용해야하는 경우 단어의 표준 약어와 상충되는 경우에도 두 개 이상의 문자로 구성된 약어에 낙타 대소 문자를 사용하십시오.

합산:

• 두 글자 길이의 약어 또는 머리 글자를 사용할 때는 모두 대문자로 입력하십시오.

• 약어가 두 문자보다 길면 첫 문자에 대문자를 사용하십시오.

따라서 특정 경우 getUnescoProperties()에는 정확합니다.

허용 된 답변에서 Microsoft 조언에 대한 합법적 인 비판이 있습니다 .

• 문자 수에 따라 두문자어 / 초기화가 일관되지 않은 처리 :
  • playerID대 playerId대 playerIdentifier.
• 두 글자의 약어가 식별자의 시작 부분에 나타날 경우 여전히 대문자로 표시해야하는지에 대한 질문 :
  • USTaxes vs usTaxes
• 여러 약어를 구별하는 데 어려움이 있습니다.
  • 즉 USIDvs usId(또는 parseDBMXMLWikipedia의 예).

따라서이 답변을 수락 된 답변의 대안으로 게시하겠습니다. 모든 약어는 일관되게 처리해야합니다. 약어는 다른 단어와 같이 취급해야합니다. 인용 위키 백과 :

... 일부 프로그래머는 약어를 소문자로 사용하는 것을 선호합니다 ...

다시 : OP의 질문, 나는 받아 들인 대답에 동의합니다. 이것은 맞습니다 :getUnescoProperties()

그러나 나는이 예제에서 다른 결론에 도달 할 것이라고 생각합니다.

• US Taxes → usTaxes
• Player ID → playerId

따라서 두 글자의 약어가 다른 약어와 같이 취급되어야한다고 생각되면이 답변에 투표하십시오..

낙타 케이스는 규격이 아니라 관습입니다. 그래서 나는 대중의 의견 규칙을 추측합니다.

( 편집 : 투표 가이 문제를 결정해야한다는 제안을 제거하십시오. @ Brian David가 말했듯이; 스택 오버플로는 "인기 경연 대회"가 아니며이 질문은 "의견 기반"으로 마감되었습니다)

많은 사람들이 두문자어를 다른 단어처럼 취급하는 것을 선호하지만, 더 일반적인 관행은 두문자어에 약어를 두는 것입니다 ( "상실"을 초래하더라도)

• 이 XML 스키마의 "EDXML"을 참조하십시오.
• 이 XBRL 스키마의 "SFAS158"을 참조하십시오.

기타 자료 :

• 일부 사람들은 약어와 두문자어를 구별합니다.
• 참고 Microsoft 지침에서는 두 문자 약어와 "두 문자 이상의 길이"를 구별합니다.
• 어떤 사람들은 약어 / 두문자어를 피하는 것이 좋습니다
• 어떤 사람들은 CamelCase / PascalCase를 함께 피하는 것이 좋습니다
• 어떤 사람들은 "일관성"을 "내부적으로 일관성이없는 것처럼 보이는 규칙"(즉, 3 문자 약어와 다른 2 문자 약어 처리)로 구분합니다. 어떤 사람들은 "일관성"을 "일관된 규칙을 일관되게 적용"하는 것으로 정의합니다 (규칙이 내부적으로 일치하지 않더라도)
• 프레임 워크 디자인 지침
• Microsoft 지침

먼저, 나는 영어 원어민이 아님 을 분명히해야 하므로 영어 문법에 대한 나의 주장은 단순히 틀릴 수 있습니다. 이러한 오류를 발견하면 알려 주시면 매우 감사하겠습니다.

약어의 모범 사례는 가능한 약어를 피하는 것입니다. 어쨌든 약어 UNESCO는 이름보다 친숙 하기 때문에 그렇지 않습니다 UnitedNationsEducationalScientificAndCulturalOrganization.

그런 다음 단순히 실제 형태에 더 가깝기 때문에 UNESCO더 이해가된다고 생각 합니다 Unesco. 나는 그 단어가 Unesco실제로 무엇을 의미 하는지 알아내는 데 어려움을 겪었습니다 .

다른 예로,에 대해 생각해보십시오 Arc. 이것은 원 주위의 곡선처럼 들리지만 녹에서는을 의미 Atomically Reference Counted합니다. 다음과 같이 쓰여졌다면 ARC, 적어도 독자들은 그 단어가 일종의 곡선이 아닌 다른 것의 약어임을 인식 할 것입니다.

현대 프로그램은 주로 인간 독자를 위해 작성되었습니다. 그런 다음 이러한 이름 지정 규칙을 기계 처리 또는 분석이 아닌 사람이 읽을 수 있도록 설정해야합니다 .

이 관점에서, 우리는 아무것도 얻지 않고 Unescoover UNESCO를 사용함으로써 가독성을 잃 습니다.

그리고 다른 모든 경우에, 나는 가장 쉬운 가독성을 위해 일반 영어 약어 규칙 (또는 규칙)을 따르는 것으로 충분 하다고 생각 합니다.

CamelCase로 변환하기 위해 Google의 (거의) 결정 론적 Camel 사례 알고리즘도 있습니다 .

이름의 산문 형식으로 시작 :

1. 문구를 일반 ASCII로 변환하고 아포스트로피를 제거하십시오. 예를 들어 "Müller의 알고리즘"은 "Muellers 알고리즘"이 될 수 있습니다.
2. 이 결과를 단어로 나누고 공백과 나머지 구두점 (일반적으로 하이픈)을 나눕니다.
   1. 권장 : 일반적인 사용법에서 기존 낙타 케이스 모양의 단어가 이미있는 경우이를 구성 부분으로 나눕니다 (예 : "애드워즈"는 "애드 워드"가됩니다). "iOS"와 같은 단어는 실제로 낙타 경우가 아닙니다. 이 규칙은 무시되므로이 권장 사항은 적용되지 않습니다.
3. 이제 소문자 (약어 포함)를 모두 소문자로 한 다음 대문자의 첫 문자 만 대문자로 입력하십시오.
   1. … 각 단어는 대문자 낙타 경우 또는
   2. … 첫 번째를 제외한 각 단어는 낮은 낙타 사건을 산출합니다.
4. 마지막으로 모든 단어를 단일 식별자로 결합하십시오.

원래 단어의 대소 문자는 거의 전적으로 무시됩니다.

다음 예에서 "XML HTTP 요청"이 XmlHttpRequest로 올바르게 변환되고 XMLHTTPRequest가 올바르지 않습니다.

getUnescoProperties() 최고의 솔루션이어야합니다 ...

가능하면 순수한 것을 따르십시오. camelCase두문자어가 있으면 가능한 경우 대문자를 그대로 두십시오 camelCase.

일반적으로 OO 프로그래밍 변수에서 소문자 ( lowerCamelCase)로 시작하고 클래스는 대문자 ( )로 시작해야합니다 UpperCamelCase.

의심 스러울 때 순전히 camelCase;)

parseXML좋은이며, parseXml또한camelCase

XMLHTTPRequest후속 대문자 약어와 함께 갈 수 XmlHttpRequest없거나 xmlHttpRequest없어야하는 것은 아니며, 모든 테스트 사례에서 명확하지는 않습니다.

예를 들어, 당신은 어떻게이 단어를 읽습니까 HTTPSSLRequest, HTTP + SSL또는 HTTPS + SL(평균 아무것도하지 않습니다하지만 ...),이 경우 추적 낙타 경우 규칙과 갈 httpSslRequest거나 httpsSlRequest어쩌면 더 이상 좋은,하지만 확실히 더 분명하다.

이 자바 스크립트 스타일 가이드 에어 비앤비 별 (~이 순간에 57.5k) 약 및 가이드의 많은 GitHub의에 약어 말 :

약어 및 초기 법은 항상 모두 대문자이거나 모두 소문자 여야합니다.

왜? 이름은 가독성을위한 것이며 컴퓨터 알고리즘을 진정시키는 것이 아닙니다.

// bad
import SmsContainer from './containers/SmsContainer';

// bad
const HttpRequests = [
  // ...
];

// good
import SMSContainer from './containers/SMSContainer';

// good
const HTTPRequests = [
  // ...
];

// also good
const httpRequests = [
  // ...
];

// best
import TextMessageContainer from './containers/TextMessageContainer';

// best
const requests = [
  // ...
];

현재 다음 규칙을 사용하고 있습니다.

1. 약어에 대한 자본의 경우 : XMLHTTPRequest, xmlHTTPRequest, requestIPAddress.

2. 약어에 대한 낙타의 경우 : ID[entifier], Exe[cutable], App[lication].

ID 죄송하지만 사실은 예외입니다.

대문자를 볼 때 나는 약어, 즉 각 문자에 대한 별도의 단어를 가정합니다. 약어는 각 글자마다 별도의 단어가 없으므로 낙타 경우를 사용합니다.

XMLHTTPRequest 모호하지만 드문 경우이며 모호하지 않으므로 규칙과 논리가 아름다움보다 중요합니다.

JavaScript 에어 비앤비 스타일 가이드 는 이것에 대해 조금 이야기합니다 . 원래:

// bad
const HttpRequests = [ req ];

// good
const httpRequests = [ req ];

// also good
const HTTPRequests = [ req ];

일반적으로 대문자로 된 대문자를 수업으로 읽었으므로이를 피하는 경향이 있습니다. 하루가 끝나면 모든 것이 선호됩니다.

@ valex가 말한 것 외에도이 질문에 대한 주어진 답변으로 몇 가지를 요약하고 싶습니다.

일반적인 답변은 사용중인 프로그래밍 언어에 따라 다릅니다.

C 샤프

Microsoft 는HtmlButton 이 경우에 클래스 이름을 지정하는 올바른 방법으로 보이는 몇 가지 지침 을 작성 했습니다.

자바 스크립트

Javascript에는 두문자어가있는 일부 전역 변수가 있으며 모두 대문자로 사용하지만 항상 일관성있게 웃기는 것은 아닙니다. 여기 몇 가지 예가 있습니다.

encodeURIComponent XMLHttpRequest toJSON toISOString

면책 조항 : 영어는 모국어가 아닙니다. 그러나 테이블 필드 이름을 뱀으로 만들어야하기 때문에 노드 (카멜 케이스 스타일)를 사용하여 데이터베이스를 처리 할 때이 문제에 대해 오랫동안 생각했습니다. 이것은 내 생각입니다.

프로그래머에게는 두 가지 종류의 '약어'가 있습니다.

• 자연어, 유네스코
• 컴퓨터 프로그래밍 언어 (예 tmc and textMessageContainer:로 지역 변수로 표시됨)

프로그래밍 세계에서 자연어의 모든 약어는 단어 로 취급되어야하며 그 이유는 다음과 같습니다.

1. 프로그래밍 할 때 약어 스타일 또는 비 약어 스타일로 변수 이름을 지정해야합니다. 우리가 함수 getUNESCOProperties 이름을한다면, 그것은 유네스코가 약어 (그렇지 않으면 모두 대문자 문자 안)이지만, 분명히 의미 get와 properties두문자어 수 없습니다. 따라서이 함수의 이름을 gunescop 또는 getUnitedNationsEducationalScientificAndCulturalOrganizationProperties로 지정해야합니다 . 둘 다 허용되지 않습니다.

2. 자연어는 지속적으로 발전하고 있으며 오늘날의 약어는 어마 어마한 단어가 될 것입니다 . 그러나 프로그램은 이러한 추세와 무관하며 영원히 서 있어야합니다.

그런데 가장 투표가 많은 답변에서 IO는 컴퓨터 언어 의미의 약어 (InputOutput의 약자)입니다. 그러나 컴퓨터 언어의 약어는 이름을 지정하는 데만 사용해야하기 때문에 이름이 마음에 들지 않습니다. 로컬 변수이지만 최상위 클래스 / 함수이므로 IO 대신 InputOutput을 사용해야합니다.

유네스코는 UEFA, RADA, BAFTA와 같은 약어가 아닌 단어로 읽히고 (BBC, HTML, SSL과 달리) 영어로 된 특별한 경우입니다.

대문자 ( HTML) 또는 소문자 ( html)를 사용하지만 두 가지를 피하여 두문자어의 가독성을 선호하는 또 다른 낙타 규칙이 있습니다 (Html )를 .

따라서 귀하의 경우에는 쓸 수 getUNESCOProperties있습니다. unescoProperties변수 또는 UNESCOProperties클래스를 작성할 수도 있습니다 (클래스의 규칙은 대문자로 시작하는 것임).

예를 들어 XML HTTP Request라는 클래스에 대해 두 개의 두문자어를 조합하려는 경우이 규칙이 까다로워집니다. 대문자로 시작하지만 XMLHTTPRequest읽기가 쉽지 않기 때문에 (XMLH TTP 요청입니까?), XMLhttpRequest낙타 어 규칙 (XM Lhttp 요청입니까?)을 위반하므로 최상의 옵션은 대소 문자를 혼합 XMLHttpRequest하는 것입니다. 실제로 W3C가 사용한 것 . 그러나 이런 종류의 이름을 사용하는 것은 권장되지 않습니다. 이 예에서는 HTTPRequest더 나은 이름이 될 것입니다.

식별 / 정체에 대한 공식 영어 단어는 ID 인 것처럼 보이지만 약어는 아니지만 동일한 규칙을 적용 할 수 있습니다.

이 컨벤션은 꽤 인기있는 것처럼 보이지만 컨벤션 일 뿐이며 옳고 그른 것은 없습니다. 컨벤션을 고수하고 이름을 읽을 수 있는지 확인하십시오.