_var
클래스 필드에서 변수 이름 을 보는 것이 일반적 입니다. 밑줄은 무엇을 의미합니까? 이러한 모든 특수 명명 규칙에 대한 참조가 있습니까?
답변
밑줄은 단순히 규칙입니다. 더 이상 없습니다. 따라서 그 사용은 항상 사람마다 다소 다릅니다. 문제의 두 언어에 대해 이해하는 방법은 다음과 같습니다.
C ++에서 밑줄은 일반적으로 개인 멤버 변수를 나타냅니다.
C #에서는 일반적으로 공용 속성에 기본 개인 멤버 변수를 정의 할 때만 사용됩니다. 다른 개인 멤버 변수에는 밑줄이 없습니다. 이 사용법은 자동 속성의 출현으로 대체로 길을 갔다.
전에:
private string _name;
public string Name
{
get { return this._name; }
set { this._name = value; }
}
후:
public string Name { get; set; }
답변
C ++에서 변수 이름 또는 매개 변수 이름 앞에 UNDERSCORES를 사용하지 않는 것이 좋습니다.
밑줄 또는 이중 밑줄로 시작하는 이름은 C ++ 구현자를 위해 예약됩니다. 밑줄이있는 이름은 라이브러리가 작동하도록 예약되어 있습니다.
C ++ 코딩 표준을 읽으면 첫 페이지에 다음과 같이 표시됩니다.
“명명을 과대 평가하지 말고 일관된 명명 규칙을 사용하십시오. 두 가지 필수 사항 만 있습니다. (p2, C ++ 코딩 표준, 허브 셔터 및 Andrei Alexandrescu)
보다 구체적으로, ISO 실무 초안 에는 실제 규칙이 나와 있습니다.
또한 일부 식별자는 C ++ 구현에서 사용하도록 예약되어 있으며 다른 방식으로 사용해서는 안됩니다. 진단이 필요하지 않습니다. (a) 이중 밑줄 __을 포함하거나 밑줄로 시작하고 대문자로 시작하는 각 식별자는 모든 사용을 위해 구현에 예약되어 있습니다. (b) 밑줄로 시작하는 각 식별자는 전역 네임 스페이스에서 이름으로 사용하기 위해 구현에 예약되어 있습니다.
실수로 위의 제한 중 하나에 빠질 경우 밑줄로 기호를 시작하지 않는 것이 가장 좋습니다.
소프트웨어를 개발할 때 이러한 밑줄을 사용하는 것이 왜 비참한 지 스스로 알 수 있습니다.
다음과 같이 간단한 helloWorld.cpp 프로그램을 컴파일하십시오.
g++ -E helloWorld.cpp
백그라운드에서 발생하는 모든 것을 볼 수 있습니다. 다음은 스 니펫입니다.
ios_base::iostate __err = ios_base::iostate(ios_base::goodbit);
try
{
__streambuf_type* __sb = this->rdbuf();
if (__sb)
{
if (__sb->pubsync() == -1)
__err |= ios_base::badbit;
else
__ret = 0;
}
이중 밑줄로 시작하는 이름의 수를 볼 수 있습니다!
또한 가상 멤버 함수를 보면 * _vptr은 클래스에서 하나 이상의 가상 멤버 함수를 사용할 때 자동으로 생성되는 가상 테이블에 대해 생성 된 포인터임을 알 수 있습니다! 그러나 그것은 또 다른 이야기입니다 …
밑줄을 사용하면 충돌 문제가 발생할 수 있으며 너무 늦을 때까지 그 원인을 파악할 수 없습니다.
답변
실제로이 _var
규칙은 C #이나 C ++가 아닌 VB에서 나옵니다 (m _, …는 또 다른 것입니다).
이는 속성을 선언 할 때 VB의 대 / 소문자 구분을 극복했습니다.
예를 들어, 이러한 코드는 고려되기 때문 VB에서 불가능 user
와 User
동일한 식별자
Private user As String
Public Property User As String
Get
Return user
End Get
Set(ByVal Value As String)
user = value
End Set
End Property
이를 극복하기 위해 일부 사람들은 ‘_’을 개인 필드에 추가하여 다음과 같이 표시했습니다.
Private _user As String
Public Property User As String
Get
Return _user
End Get
Set(ByVal Value As String)
_user = value
End Set
End Property
많은 규칙이 .Net에 대한 것이며 C #과 VB.NET 규칙간에 균일 성을 유지하기 위해 동일한 규칙을 사용하고 있습니다.
내가 말한 것에 대한 참조를 찾았습니다 :
http://10rem.net/articles/net-naming-conventions-and-programming-standards—best-practices
밑줄이있는 낙타 케이스. VB.NET에서 항상 “Protected”또는 “Private”를 표시하고 “Dim”을 사용하지 마십시오. “m_”의 사용은 권장되지 않는 보호 된 변수의 경우에만 속성과 다른 경우에만 속성과 다른 변수 이름을 사용하지 않는 것이 좋습니다. VB.NET에서 프로그램을 프로그래밍 할 때 삶을 고통스럽게 할 수 있습니다. 접근 자 / 돌연변이 속성과 다른 이름을 멤버에 지정해야합니다. 여기에있는 모든 항목 중 주요 밑줄은 실제로 유일한 논란입니다. 개인적으로 변수에 밑줄이없는 낙타보다 선호하기 때문에 변수 이름을 “this”로 한정 할 필요가 없습니다. 이름 충돌이 발생할 가능성이있는 생성자 또는 다른 곳의 매개 변수와 구별하기 위해. VB.NET의 대소 문자를 구분하지 않으면 접근 자 속성의 이름이 밑줄을 제외하고 개인 멤버 변수와 같은 이름을 가지므로 더욱 중요합니다. m_가가는 한, 그것은 실제로 미학에 관한 것입니다. 변수 이름에 구멍이있는 것처럼 보이기 때문에 나 (그리고 다른 많은 사람들)는 m_ ugly를 찾습니다. 거의 모욕적입니다. 나는 항상 VB6에서 그것을 사용했지만 변수는 선행 밑줄을 가질 수 없었기 때문입니다. 나는 그것이 사라지는 것을보고 더 행복 할 수 없었다. 코드에서 두 가지를 모두 수행했지만 m_ (및 직선 _)을 사용하지 않는 것이 좋습니다. 또한, “m”으로 시작하는 접두사도 있습니다. 물론 이들은 주로 C #으로 코딩되므로 속성과 경우에만 다른 개인 멤버를 가질 수 있습니다. VB 사람들은 다른 일을해야합니다. 언어 별 특수한 경우를 시도하기보다는이를 지원할 모든 언어에 대해 밑줄을 사용하는 것이 좋습니다. 클래스가 CLS를 완전히 준수하도록하려면 C # 보호 멤버 변수의 접두사를 생략 할 수 있습니다. 그러나 실제로 잠재적으로 보호되는 모든 멤버 변수를 비공개로 유지하고 대신 보호 된 접근 자와 뮤 테이터를 제공하므로 걱정할 필요가 없습니다. 이유 : 간단히 말해서,이 규칙은 간단하고 (한 문자), 읽기 쉬우 며 (눈이 다른 주요 문자에 방해가되지 않음) 절차 수준 변수 및 클래스 수준 속성과의 이름 충돌을 성공적으로 피할 수 있습니다. . 지원할 모든 언어에 대해 밑줄을 사용하는 것이 좋습니다. 클래스가 CLS를 완전히 준수하도록하려면 C # 보호 멤버 변수의 접두사를 생략 할 수 있습니다. 그러나 실제로 잠재적으로 보호되는 모든 멤버 변수를 비공개로 유지하고 대신 보호 된 접근 자와 뮤 테이터를 제공하므로 걱정할 필요가 없습니다. 이유 : 간단히 말해서,이 규칙은 간단하고 (한 문자), 읽기 쉬우 며 (눈이 다른 주요 문자에 방해가되지 않음) 절차 수준 변수 및 클래스 수준 속성과의 이름 충돌을 성공적으로 피할 수 있습니다. . 지원할 모든 언어에 대해 밑줄을 사용하는 것이 좋습니다. 클래스가 CLS를 완전히 준수하도록하려면 C # 보호 멤버 변수의 접두사를 생략 할 수 있습니다. 그러나 실제로 잠재적으로 보호되는 모든 멤버 변수를 비공개로 유지하고 대신 보호 된 접근 자와 뮤 테이터를 제공하므로 걱정할 필요가 없습니다. 이유 : 간단히 말해서,이 규칙은 간단하고 (한 문자), 읽기 쉬우 며 (눈이 다른 주요 문자에 방해가되지 않음) 절차 수준 변수 및 클래스 수준 속성과의 이름 충돌을 성공적으로 피할 수 있습니다. . 잠재적으로 보호되는 모든 멤버 변수를 비공개로 유지하고 대신 보호 된 접근 자와 뮤 테이터를 제공하므로 걱정할 필요가 없습니다. 이유 : 간단히 말해서,이 규칙은 간단하고 (한 문자), 읽기 쉬우 며 (눈이 다른 주요 문자에 방해가되지 않음) 절차 수준 변수 및 클래스 수준 속성과의 이름 충돌을 성공적으로 피할 수 있습니다. . 잠재적으로 보호되는 모든 멤버 변수를 비공개로 유지하고 대신 보호 된 접근 자와 뮤 테이터를 제공하므로 걱정할 필요가 없습니다. 이유 : 간단히 말해서,이 규칙은 간단하고 (한 문자), 읽기 쉬우 며 (눈이 다른 주요 문자에 방해가되지 않음) 절차 수준 변수 및 클래스 수준 속성과의 이름 충돌을 성공적으로 피할 수 있습니다. .
답변
첫 번째 주석 자 (R Samuel Klatchko) 는 다음과 같이 언급했습니다. C ++ 식별자에 밑줄을 사용하는 것에 대한 규칙은 무엇입니까? C ++의 밑줄에 대한 질문에 대답합니다. 일반적으로 컴파일러의 구현자를 위해 예약되어 있으므로 밑줄을 사용하지 않아야합니다. 당신이보고있는 코드 _var
는 아마도 레거시 코드이거나 오래된 밑줄을 찌르지 않는 오래된 명명 시스템을 사용하여 자란 누군가가 작성한 코드 일 것입니다.
다른 답변 상태로, 클래스 멤버 변수를 식별하기 위해 C ++에서 사용되었습니다. 그러나 데코레이터 나 구문이 사용되는 한 특별한 의미는 없습니다. 그래서 당신이 그것을 사용하려면 컴파일됩니다.
C # 토론을 다른 사람에게 맡기겠습니다.
답변
_var은 의미가 없으며 변수가 전용 멤버 변수임을 쉽게 구별 할 수 있도록하는 목적으로 만 사용됩니다.
C ++에서는 식별자 앞에 밑줄 사용을 제어하는 규칙이 있기 때문에 _var 규칙을 사용하는 것은 잘못된 형식입니다. _var은 전역 식별자로 예약되어 있으며 _Var (밑줄 + 대문자)은 언제든지 예약되어 있습니다. 이것이 C ++에서 var_ 규칙을 대신 사용하는 사람들을 보는 이유입니다.
답변
고유 한 코딩 지침을 만들 수 있습니다. 나머지 팀을 위해 명확한 문서를 작성하십시오.
_field를 사용하면 Intelilsense에서 _ 만 입력하면 모든 클래스 변수를 필터링 할 수 있습니다.
나는 보통 Brad Adams Guidelines 를 따르지만 밑줄을 사용하지 않는 것이 좋습니다.
답변
C #의 Microsoft 명명 표준에 따르면 변수와 매개 변수는 소문자 낙타 경우 IE :를 사용해야합니다 paramName
. 필드가 같은 양식을 할 수 있지만, 많은 팀이 명확하게 개선하기 위해 밑줄 접두사를 요구 있도록이 불분명 코드로 이어질 수에 대한 표준도 호출 IE를 : _fieldName
.