[coding-style] CamelCase의 약어 [닫힘]

허용 된 답변에서 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 지침

답변

// 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 = [
  // ...
];