CamelCase의 약어

CamelCase의 약어 [닫힘]

---

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

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

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

그리고 기존 코드 또는 마크 업에서 "인기"답변을 검색 할 때 허용되는 답변이 맞을 수 있습니다.

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

---

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

---

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

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

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

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

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

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

---

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

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

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

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

parseXML좋은이며, parseXml또한camelCase

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

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

---

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

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

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

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

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

---

이 자바 스크립트 스타일 가이드 에어 비앤비 별 (~이 순간에 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 모호하지만 드문 경우이며 모호하지 않으므로 규칙과 논리가 아름다움보다 중요합니다.

---

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

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

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

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

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

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

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

---

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

// bad
const HttpRequests = [ req ];

// good
const httpRequests = [ req ];

// also good
const HTTPRequests = [ req ];

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

---

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

일반적인 대답은 다음과 같습니다. 사용하는 프로그래밍 언어에 따라 다릅니다.

C 샤프

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

자바 스크립트

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

encodeURIComponent XMLHttpRequest toJSON toISOString

---

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

---

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

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

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

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

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

참고 URL : https://stackoverflow.com/questions/15526107/acronyms-in-camelcase