밑줄로 변수 / 멤버를 시작하면 컴파일러가 퍼즐을 풀 수 있습니까?

고등학교 이후부터 다음과 같은 변수를 정의하는 법을 배웠습니다.

int _a;

또는

int __a;

결과적으로 밑줄로 시작하는 변수를 사용하여 임시 변수의 이름을 지정하는 컴파일러를 혼란스럽게하므로 나쁜 습관을 고려해야합니다.

내가 아는 한 일부 사람들은 이름 끝에서 밑줄을 다음과 같이 이동하는 이유입니다.

int a_;

그러나 밑줄 시작 변수를 사용하는 많은 코드가 있습니다. 그리고이 코드는 Visual Studio 2010과 g ++ 4.x에서 상당히 잘 구축됩니다.

그래서 나는 이것이 궁금합니다 : 요즘 이것이 문제가 아닌가? 현대 컴파일러는 명명 규칙에 대해 더 똑똑합니까?

c++ programming-practices naming-standards

— 에밀리아 노
소스

실제 답변은 아니지만 Microsoft의 C ++ 컴파일러는 개인 멤버 변수 앞에 적어도 밑줄을 사용하는 Microsoft의 내부 스타일 (적어도 C #에서는)이기 때문에 특히 더 관대합니다. g ++에는 여전히 밑줄과 관련된 문제가있을 수 있음을 알고 있습니다.

— KChaloux

이 질문에 대한 답변 이 도움 이 될 수 있습니다 .

— Blrfl

@KChaloux 20 년 넘게 존재하는 Microsoft의 C ++ 컴파일러 팀이 C # 팀의 일부 사람들의 습관을 기반으로 허용되는 식별자 이름에 대한 규칙을 설정했다면 Microsoft의 작동 방식을 모릅니다. 진지하게, 첫 C ++ 컴파일러를 출시 한 지 21 년이 지났으며이 규칙은 그 정도까지, 또는 원래의 C 컴파일러 코드베이스로 거슬러 올라갑니다.

— Kate Gregory

@ Kate 나는 그들이 C #에서 그것을 사용한다는 사실을 알고 있다고 지적했습니다. Microsoft의 C ++ 컴파일러를 사용하지 않거나 환경에 대해 많이 알고 있으므로 C #에 대한 경험을 통해 C ++에서 해당 명명 스타일을 사용하는 것으로 추론했습니다. C # 규칙이 처음이라고 주장한 적이 없습니다 .

— KChaloux

답변:

접두사 밑줄이 좋지 않은 이유를 분명히 이해하고 있습니다. 간단히 말해 C 및 C ++ 표준은 구현 세부 사항 (예 : 표준 라이브러리 구현)을 위해 이러한 접 두부를 예약하기 때문입니다. (_와 __은 같은 것을 위해 예약되어 있지 않습니다. 주석 참조)

이름이 범위 (네임 스페이스, 클래스 등)에 속하더라도 일부 접두사를 사용하는 전역 이름, 특히 매크로가있을 수 있습니다.이 접두사를 사용하면 코드를 자동으로 중단 할 수도 있습니다.

따라서 기본적으로 이러한 접두사를 사용하는 것이 안전하지만 대부분 사용하지 않으면 이름이 구현 이름과 충돌하지 않는다는 100 % 보장이 있습니다.

의심 할 여지없이 이러한 접두사를 사용하지 않는 이유가 여기에 있습니다.

— 클라 임
소스

귀하의 의견은 두 개의 밑줄 접두사에는 적용되지만 단일 밑줄에는 적용되지 않습니다

— Kate Gregory

@KateGregory : 밑줄이 맨 앞에 붙은 이름은 전역 네임 스페이스의 이름을 구현할 때 사용하도록 예약되어 있습니다. 밑줄 또는 두 번째 밑줄 다음에 오는 밑줄은 모든 용도로 예약되어 있습니다 (구현에 의해 매크로에 사용될 수 있음). 따라서 밑줄과 소문자로 시작하는 밑줄은 로컬 범위에서 괜찮을 수 있지만 예약 된 이름을 사용하여 넘어지지 않도록하는 것이 가장 좋습니다.

— Bart van Ingen Schenau

@KateGregory : 멤버로서 _limit오류는 아니지만 전역 함수입니다. "예외 밑줄을 예외없이 사용하지 마십시오"라는 간단한 정책을 사용하는 것이 다른 상황에서는 허용되지 않고 다른 상황에서는 허용하는 정책보다 낫다고 생각합니다. 그러나 우리는 그것에 다른 의견에 동의 할 수 있습니다. 그리고 명확히하기 위해, 나는 처음부터 다른 곳에서 밑줄에 문제가 없습니다.

— Bart van Ingen Schenau

@BartvanIngenSchenau : 단지 관심을 끌기 위해 : "단독 밑줄을 개인 클래스 멤버에게만 사용"과 같은 간단한 정책은 기술적 문제로 이어지지 않아야한다고 생각합니다.

— Doc Brown

@KateGregory 명확히하기 위해, 나는 규칙이 내가 대답에서 말하는 것보다 더 정확하다는 데 동의합니다. 그러나 그것은 정확히 규칙이 무엇인지 기억하려고 할 때 내 기억의 정확성 부족을 반영합니다. 필자는 예외 (기능이 아님)를 알 필요가없는 경향이 있기 때문에 특히 중요하지 않은 규칙에 대해서는 쉽게 따르는 일반적인 규칙을 선호합니다. 재미있는 점은 이것을 기억하는 것보다 이동 의미론이 더 편하다는 것입니다. 어쩌면 그것은 내가 지금 그것에 대해 생각하는 재미되지 않을 수도 있습니다 ...

— Klaim

두 개의 밑줄을 사용하는 것은 분명히 나쁘다-그것은 컴파일러 특정 구현 세부 사항을 위해 예약되어 있습니다. 하나의 밑줄을 사용하는 경우에는 적용되지 않습니다.

어떤 사람들은 밑줄을 싫어합니다. 당신은 뭔가를 호출 여부 m_index나 highest_price또는 _a- 그들이 혐오를. 나는 25 년 전에 누군가와 협력하여 다른 모든 줄의 맨 아래 픽셀을 생략하여 페이지의 더 많은 줄에 맞는 특정 IBM 프린터 (매우 인기있는 프린터)에 대해 이야기했습니다. 이것은 메모 또는 큰 숫자의 스와 스 출력에 좋았지 만 밑줄의 절반을 보이지 않게하는 코드에는 효과가있었습니다. (예, 정말로!) 그 세대의 사람들은 일반적으로 해당 프린터와의 상호 작용 또는 밑줄을 사용하지 않아야하는 프린터와의 대화에서 비합리적인 밑줄 미움을받습니다.

대부분의 사람들이 혼합 된 경우 (우리가에서이 말을하지 않았다 옵션, 포트란)을 더 읽기 방법을 사용하여 찾을 수 있습니다 : mIndex, HighestPrice, a앞의 밑줄 예에 꽤 잘 서있다. 두 가지 규칙을 알려 드리겠습니다.

두 개의 밑줄로 아무것도 시작하지 마십시오 (함수, 변수, 매크로, typedef)
일관성있는 규칙을 선택합니다 (예 : _limit기능 매개 변수, m_limit멤버 변수에 대한 모든 단어, 헝가리어, 대문자, 밑줄, 카멜 케이스를 사용하지 않을 것을 그것과 스틱). 시작 부분에 밑줄, 때로는 끝 부분, 때로는 사용하지 않는 경우 및 5 가지의 다른 케이싱 규칙을 사용하지 마십시오. 일관성을 유지하십시오.

문제의 프린터가 오랫동안 사라졌습니다. 한 번에 하나의 밑줄을 사용하려면 마음대로하십시오. 그러나 밑줄 증오가 여전히 존재한다는 것을 이해하십시오.

— 케이트 그레고리
소스

"무엇을 m_index 또는 high_price 또는 _a라고 부르든간에 그들은 그것을 혐오한다"이유없이! 표준에 밑줄을 식별자로 사용하는 것과 관련된 규칙이 있다는 언급은 없습니다. 쉽게 피할 수있을 때 문제를 묻는 이유는 무엇입니까? stackoverflow.com/a/228797

— Max Barraclough 2016 년

언급하지 않았다? 첫 문장을 다시 읽으십시오.

— Kate Gregory

"이것은 하나의 밑줄을 사용하는 경우에는 적용되지 않습니다"는 전체 이야기가 아닙니다. 내 링크를 참조하십시오. 이중 밑줄로 이어지는 것은 확실히 확실한 것은 아니지만 "글로벌 네임 스페이스에서 예약 됨 : 밑줄". 왜 불을 가지고 노는가?

— Max Barraclough

좋아, 요점을 놓쳤다. 두 번째 단락은 일반적으로 반 밑줄을 가진 사람들의 존재를 논의하는 것입니다. 밑줄을 선행하지 않습니다. 모든 밑줄. 그렇습니다. 두 개의 밑줄에 대한 규칙 외에도 대문자와 밑줄, 글로벌 범위 등의 밑줄과 같은 규칙이 있지만 일부 사람들은 어쨌든 밑줄을 싫어합니다. 그리고 그 사람들은 내가 잘못 부르는 것을 좋아합니다. 비 밑줄에 반대하는 표준 기반 이유는 없습니다. 그러나 사람들은 어쨌든 그렇게합니다.

— Kate Gregory

그것이 우리가 동의하지 않는 곳입니다. 그렇습니다 . 단일 밑줄로 식별자를 시작하는 것이 합법적 인 경우가 있습니다. 위에 놓았을 때 왜 불을 가지고 노는가? 밑줄로 식별자를 시작하지 않습니다. 나는 그것을 코드 냄새로 본다 (만약 냄새를 '보기'라고 말할 수 있다면 :-P). 그렇게하면 합법적 인시기를 정확하게 알려주는 규칙의 세부 사항에 대해 걱정하지 않아도됩니다.

— Max Barraclough