C ++에는 일반적인 대문자 표기법이 있습니까? [닫은]

파이썬과 자바에서 많은 작업을 수행하고 그 언어 모두 (보편적 아니지만) 총액은 식별자에 사용하는 방법에 대한 규칙 매우 일반적인 있습니다 모두 사용할 PascalCase클래스 이름과 ALL_CAPS"글로벌"상수에 대한하지만, 다른 식별자 A에 대한 많은 Java 코드가 사용 mixedCase하는 반면 많은 Python 코드가 사용합니다 underscore_delimiters. 언어 나 라이브러리가 특정 대문자를 강제 하지는 않는다는 것을 알고 있지만 사용중인 언어에 대한 표준 규칙을 고수하면 코드를 훨씬 더 읽기 쉽다는 것을 알았습니다.

이제 C ++에서 프로젝트를 시작하고 있으며 동일한 아이디어를 적용하고 싶습니다. 내가 알아야 할 가장 일반적인 대문자 표기법이 있습니까?

내가 알아야 할 가장 일반적인 대문자 표기법이 있습니까?

C ++는 C를 기반으로하며 C ++가 발명 될 때까지 많은 명명 규칙을 개발할만큼 오래되었습니다. 그런 다음 C ++은 몇 가지를 추가했으며 C는 새로운 것을 생각하면서 유휴 상태가 아닙니다. 그들은 즉 ... C와 C ++에 다시-수정 된 점에 더 자신의 발명자의 C 명명 규칙을 개발하는 많은 C에서 파생 된 언어, 있음에 추가 : C ++에서이없는 한, 그러나 많은 그런 규칙의.

그러나 하나의 이름 지정 규칙을 찾고 있다면 표준 라이브러리의 이름 지정 규칙을 볼 수도 있습니다 . 왜냐하면 모든 C ++ 개발자가 알고 사용해야하는 단일 규칙 이기 때문입니다.

그러나 가장 중요한 규칙을 사용하는 것은 다음 과 같습니다 . 일관성을 유지하십시오!

흥미롭게도, 나는 PascalCase와 camelCase를 혼합하여 시작했고 훨씬 더 많은 명명 규칙을 가진 수많은 프로젝트에 참여했지만 수년 동안 standard_library_convention에 점점 더 많이 붙어 있습니다. 이유를 묻지 마십시오.

모든 대문자가 눈에 띄고 최소화되어야함에 먼저 동의합시다.

따라서 C와 C ++에서는 매크로가 악의가 아니라 똑같이 추악하기 때문에 매크로와 매크로에 대한 규칙으로 사용됩니다.

초기 C에는 const가 없었으므로 상수는 매크로로 표현해야했습니다. 또한 초기에는 프로그램이 훨씬 짧았으므로 오늘날 좋지 않은 관행을 사용할 수 있습니다 (예 : IIRC Brian Kernighan은 대문자가 아닌 많은 매크로로 코드를 작성했습니다). 또한 당시에는 소문자가없는 키보드가 존재했습니다. 나는 노르웨이 Tandberg EC-10 컴퓨터에서 1980 또는 1979 년경에 그런 것을 사용했다고 생각합니다.

따라서 Java는 초기 C에서 상수에 대한 대문자 규칙을 선택했습니다. 한편, 아마도 그 이전에도 (여기서 연대기가 확실하지 않습니다) C는 상수를 얻었습니다. 그러나 물론 일부 / 많은 C 프로그래머들이 대문자 매크로로서 상수의 초기 규칙에 따라 달라졌지만 C ++ 프로그래머는 더 현명했습니다.

요즘 큰 문제는 사람들이 Java를 먼저 배우거나 C (중세의 관습이있는)를 먼저 배운 다음 C ++에 와서 파울 대문자 컨벤션을 취하는 것입니다.

그래서,

    int const answer = 42;    // Nice, good, OK.
    const int ANSWER = 0x2A;  // Ouch!
    #define COMPANYNAME_ANSWER 052  // Oh kill me, please.

글쎄, jest에서 대문자 전용 키보드를 언급했다고 생각했을 것입니다. 아뇨 이는 명명 규칙을 주도하거나 최소한 잘못 / 올바른 것처럼 보이는 데 영향을 미치는 가장 오래되고 가장 오래된 기술 제한 일뿐입니다. 다음으로, 7 비트 직렬 전송 문제로 인해 사용 된 문자 코드 (뉴스 피크 문자 인코딩)에 해당하는 문제가 발생하여 영어 알파벳 A부터 Z까지의 문자로 제한해야했습니다.

실제로 나는 여전히 그렇게하는 것이 좋습니다. 그것이 우리가있는 곳입니다! 더 이상 얻지 못했습니다.

현재 표준 C ++은 2011 년 현재 일반적인 유니 코드 이름을 지원하지만 1998 년부터 그렇게했습니다. 실제 C ++ 구현은 그렇지 않습니다. 특히 g ++ 컴파일러는 국가 특성에 도전합니다. 그것은 암흑 시대의 기술적 한계에서 비롯됩니다.

그래서,

    double blueberryJamViscosity  = 0.0;    // OK
    double blåbærsyltetøyViskositet = 0.0;  // Ouch!

마지막으로, 밑줄 대 산재 된 대문자의 주제에 대해

• 형식 이름으로 쉽게 인식 할 수있는 양식을 예약하십시오.
• 매크로를 위해 대문자를 모두 예약하십시오.
• 일관성을 유지하십시오.

"일반적으로 (루프, 템플릿 매개 변수, blah blah를 제외하고 단일 문자 이름을 피하십시오") 및 "l을 사용하지 마십시오. 0 "으로. 또한 밑줄로 시작하고 대문자로 끝나거나 두 개의 연속 밑줄을 포함하거나 밑줄로 시작하여 전역 네임 스페이스에있는 것과 같은 예약 된 이름을 사용하지 마십시오.

건배 & hth

나는 일반적으로 언어에 대한 기존 코드베이스에서 가장 많이 보는 규칙을 고수하는 경향이 있습니다. C ++의 경우 일반적으로 camelCase가 표시됩니다. Ruby 또는 PHP의 경우 보통 stuff_like_this를 봅니다.

그러나 사실, 가장 중요한 것은 완전히 제정신이 아닌 (dOnT_dO_tHiS) 스타일 규칙을 선택하고 일관성을 유지하는 것입니다. 특정 프로젝트의 코드 전체에서 스타일이 변경되지 않도록하십시오. 기존 프로젝트에서 작업중인 경우 이미 존재하는 스타일을 사용하고 싶을 것입니다.

글쎄, 지금도 매우 흔한 시스템 헝가리어 가 있지만, 나는 그것을 추천하는 것보다 오히려 내 목을 자르고 싶습니다. 앱 헝가리어는 주석이 의미를 실제로 나타 내기 때문에 더 낫지 만 짧은 단어는 약어에 너무 예리한 느낌이 듭니다. (해당 위키 백과 페이지의 예를 사용 rw하기 위해 row한 문자 만 더 길 때 행에 사용 하는 이유 는 무엇입니까? 전체 모음이 부족한 것은 아닙니다.)

그러나 현실적으로 가장 중요한 것은 함께 일하는 사람들 의 관습을 따르는 것입니다 . 정말. 대부분의 규칙은 특히 일관되게 사용되는 경우 충분히 작동합니다. 불일치는 최악입니다 (내가 싫어하는 시스템 헝가리어보다 훨씬 더 그렇습니다). 그리고 혼자라면 원하는 것을 사용하십시오.

내가 본 것에서 프로젝트마다 다릅니다.

임베디드 밑줄은 아마도 C on Unix에서 더 전통적이거나 더 일반적으로 사용됩니다. 표준 라이브러리도이 규칙을 따르므로 다른 규칙을 사용하여 다른 규칙을 사용하도록 강제하는 기존 코드가 충분하지 않은 경우 사용 되도록 거의 기본으로 취급 해야합니다 .

Windows (일 예로)는 대부분의 기능에 낙타 케이스를 사용하므로 Windows 용으로 개발 한 소수의 사람들도 동일하게 작업합니다. 이것은 다른 언어에 더 익숙한 사람들에게도 매우 흔하며 C ++을 다른 변형의 이상한 변형처럼 취급하려고 시도합니다.

명명 규칙에 대한 참조로 표준 라이브러리와 부스트를 모두 사용했습니다. 그러나이 솔루션에 문제가 있습니다.

표준 라이브러리는 코드와의 충돌을 줄 이도록 설계된 명명 규칙을 사용합니다. 해결책의 일부는 모든 소문자를 사용하는 것입니다. 따라서 camelCase 대신 밑줄을 사용합니다.

camelCase를 읽을 수 있음을 발견했습니다. PascalCase는 적절한 명사와 동등한 클래스 이름으로 자주 사용됩니다. 그러나 동사를 더 대표하는 functors에 대해서는이 규칙을 어길 것입니다.

매크로를 사용하지 않습니다. 그러나 내가 할 때 매크로는 가능한 한 함수처럼 보이도록 만들어졌습니다. 또한 매니페스트 상수 대신 const 값이나 열거 형을 사용하므로 모든 대문자를 피할 수 있습니다. 나는 일반적으로 이러한 기호 앞에 'k'를 붙여서 상수임을 나타냅니다.

// instead of a manifest constant
#define HOURS 24

// use const
const int kHours = 24; 

// or enum
enum {
    kHours   = 24,
    kMinutes = 60
};

이 참조 는 과거에 근무한 적어도 3 개 회사에서 성공을 거 두었던 것과 비슷한 명명 규칙을 설명합니다.

나는 것이 이전의 대답과는 달리 피 , 내 자신의 코드에서 C ++ 표준 라이브러리의 명명 규칙 다음 표준 라이브러리와 피할 이름의 충돌보다 다른 이유가있는 경우.

관련 주제에 대한 이전 SO 답변도 관심이있을 수 있습니다 : /programming/228783/what-are-the-rules-about-using-an-underscore-in-ac-identifier