Microsoft가 매개 변수, 로컬 변수 및 개인 필드의 이름 명명 규칙이 동일한 이유는 무엇입니까?

나는 얼마 전에이 질문을했다 : C #에서 개인 변수의 이름을 어떻게 지정합니까?

답 중 하나에서 개인 변수 / 필드의 이름을 다음과 같이 지정해야한다는 Microsoft의 MSDN 페이지를 가리 켰습니다.

private int myInteger;

그러나 매개 변수는 다음과 같습니다.

void SomeMethod(int myInteger)

지역 변수는 다음과 같습니다.

int myInteger;

그래서 당신이 이것들을 참조 할 때

myInteger = 10;

당신은 당신이 말하는 것을 알 방법이 없습니다.

저는 지금 새로운 프로젝트를 시작하고 있으며 동료 중 한 명이 왜 적어도 이들 중 일부를 차별화하기 위해 무언가를하지 않는지 묻고 있습니다.

나는 똑같은 것을 궁금합니다. Microsoft의 표준이 왜 이러한 차이점을 유지하지 않았습니까?

원래 명명 규칙에는 클래스 멤버에 대한 m_ 접두사가 있었으며 이는 단순한 밑줄로 줄었습니다. 밑줄 접두사를 사용하는 오래된 C # Microsoft 코드가 많이 있습니다. 그러나 Tech Ed에서 한 번 밑줄이 CLS를 준수하지 않는다고 들었습니다. 나는 이것이 그들이 더 단순한 one-name-fits-all 방식으로 이동 한 이유라고 생각합니다. VB.Net의 대소 문자를 구분하지 않는 이름도 CLS 규격이 아니 었습니다.

그 가치에 대해, 나는 여전히 반원들을 위해 주요 밑줄을 사용합니다. 이것을 사용하여 명확하게 할 수 있지만 (이름과 반대되는 this.name) 버그는 여전히 해결됩니다.

MS가 지시하는 모든 것을 수행 할 필요는 없습니다.

local그리고 parameter그 범위가 동일하기 때문에 변수는 같은 방식으로 이름이 지정됩니다

개인 변수에 관해서는 다른 의견이 있습니다. 필자는 필자가 항상 논란의 여지가 있으며 Microsoft가 권장 하지 않는다고 말하지만 항상 here 에서 발견 된 표준 을 사용 했습니다.__

Wikipedia 는 C와 C ++에서

이중 밑줄 또는 밑줄과 대문자로 시작하는 이름은 구현 용으로 예약되어 있으며 (컴파일러, 표준 라이브러리) 사용해서는 안됩니다 (예 : __reserved 또는 _Reserved).

_어쨌든 많은 Microsoft 개발자 들이 자신의 개인 변수에 접두사를 사용하는 것이 잘 알려져 있지만 Microsoft가 권장하지 않는 이유 일 것입니다 .

그들이 왜 그것들을 다르게 유지하지 않았는지 확실히 말할 수 없습니다. 표준 작성에 참여한 사람이이 질문을 보지 않으면 아무도 할 수 없을 것입니다.

많은 사람들이 인스턴스 변수 앞에 _or 를 붙여서 고유 한 규칙을 만들지 만 m_실제로는 중요하지 않다고 생각합니다. 요즘 컨텍스트와 IDE에서 많은 것을 유추 할 수 있습니다. 요즘은 당신을 도울만큼 똑똑합니다. 예를 들어 ReSharper 애드온이 포함 된 Visual Studio는 로컬 변수와 인스턴스 변수를 다른 색상으로 표시합니다.

두 범위를 구별해야하는 경우 this.접두사를 사용하여 인스턴스 변수를 참조 할 수 있습니다 .

public class Test
{
    private int myInteger;

    void SomeMethod(int myInteger)
    {
        this.myInteger = 10; // sets instance variable to 10
        myInteger = 10; // does not affect the instance variable.
    }
}

다른 플러그인이 없으면 Visual Studio는 기본적으로 Intellisense를 지원합니다.

팝업은 여전히 ​​ReSharper에서 스타일을 지정할 수 있지만 ReSharper는 내장 Intellisense의 기능에 아무 것도 추가하지 않으므로 주식은 약간 다르게 보일 수 있지만 여전히 두 가지 옵션이 있습니다. )

FxCop 및 StyleCop 과 같은 코드 분석 도구를 사용 하여 변수 이름 및 범위와 관련된 잠재적 인 문제를 파악할 수 있습니다.

Microsoft의 표준이 왜 이러한 차이점을 유지하지 않았습니까?

Microsoft 직원 들은 낙타의 경우와 파스칼의 경우를 포함하여 여러 가지 규칙을 설명하는 Framework Design Guidelines 라는 책을 썼습니다 .

편집 (책에서 세부 사항 추가) :

이 책에서는 사용성 연구와 Turbo Pascal 그룹을 통해 얻은 교훈 중 일부를 언급합니다. 또한 모든 언어가 대소 문자를 구분하지는 않지만 (예 : VB), 다른 언어는 (C #과 같이), 이름에 일관성이 있어야합니다. 항목을 구별하기 위해 경우에만 차이에 의존 할 수 없습니다. 프레임 워크의 나머지 부분에서 사용되는 규칙을 고수하면 개발자의 혼동이 줄어 듭니다.

3 장 이름 지정 지침
3.1 절은 대문자 표기법입니다.

camelCasing매개 변수 이름입니다.
PascalCasing네임 스페이스, 유형 및 멤버 이름입니다. 이름의 일부로 2 자 약어가있는 경우 같이 대문자를 같이 사용하십시오 IOStream.

3.5 절은 이름 클래스, 구조체 및 인터페이스를 다룹니다.
3.6 절은 네이밍 타입 멤버를 다룹니다.
3.7 절은 이름 지정 매개 변수를 다룹니다.

그것들은 그들이 작성된 문맥에 따라 상당히 구별되기 때문에.

예를 들어, 매개 변수를 멤버 변수로 사용한 적이 있습니까? 아니면 매개 변수로 로컬 변수? 로컬 변수로서 멤버 변수는 어떻습니까?

• 모든 멤버 변수는 클래스의 "본문"에 있습니다. 나는 this비슷한 이름을 가진 지역 변수와 구별하기 위해 멤버를 접두사로 사용해야한다는 주장을 실제로 사지 않는다. 그렇지 않으면 필요하지 않다.

• 로컬 변수는 또한 메소드의 범위 또는 코드 블록 범위 내에서만 정의됩니다.

• 매개 변수는 항상 메소드 서명에서 정의됩니다.

이러한 모든 유형의 변수를 혼동하거나 혼합하여 사용하면 코드 디자인에 대해 더 많이 생각하여 더 읽기 쉽게 읽을 수 있어야합니다. 그들에게보다 더 자기 소개적인 이름을 부여하십시오 myInteger.

Microsoft 표준에 대한 질문에 답변 할 수 없습니다. 당신이 표준이 일을 구별하려는 경우, PL / SQL 매개 변수에 대한 표준 I를 사용하여 매개 변수 이름을 접두어로한다 in_, out_, io_,, 인 - OUT- 및 인 - OUT- 매개 변수. 함수에 로컬 인 변수 앞에는 접두사가 붙습니다 v_.

내가 아는 대부분의 회사는 멤버 변수의 접두사로 밑줄 또는 소문자 m ( "가정"으로 가정)을 지정하는 코딩 표준을 가지고 있습니다.

그래서

_varName

또는

mVarName

다른 사람들이 지적한 것처럼 일반적으로 범위별로 어떤 항목이 사용되는지 알 수 있습니다. 실제로 동일한 범위에 매개 변수와 로컬 변수를 가질 수 없으며 개인 변수를 원하면 this.myInteger를 사용하십시오. 따라서 원하는 경우 쉽게 구분할 수 있으므로 Microsoft가 너무 걱정하지 않는다고 생각합니다.

그러나 그것은 아직 아무도 말하지 않았지만 Microsoft와 그들의 명명 규칙에 대해 잊어 버렸습니다. 아무도 회의에 뛰어 들어 제출하지 않고 공개해야 할 때 누군가 지금까지 말했을 수도 있습니다. 그것). 헝가리어 표기법은 Microsoft에서 시작한 명명 규칙이기도했습니다 (또는 Xerox입니까? Simonyi가 언제 등장했는지 기억할 수 없습니다). 나는 오늘날까지 헝가리 표기법의 이름을 저주하지 않는 사람을 생각할 수 없다. 우리는 내가 일했던 곳에서 너무 화가 나서 내부적으로 사용했던 자체 표준을 생각해 냈습니다. 그것은 우리에게 더 의미가 있었고 우리의 작업을 조금씩 가속화했습니다 (실제로 Microsoft가 제안한 것과 거의 비슷하지만 개인 변수를 제외하고는 모든 것이 파스칼 사례였습니다).

즉, Microsoft가 사용하는 새로운 표준 (낙타 케이스와 파스칼 케이스의 혼합)은 그리 나쁘지 않습니다. 그러나 당신과 당신의 동료가 그것을 좋아하지 않는다면, 당신 자신의 표준 세트를 생각해보십시오 (통칭 적으로 최고입니다). 물론 이것은 회사에 이미 표준 세트가 있는지 여부에 따라 다릅니다. 그렇다면, 그들에게 충실하십시오. 그렇지 않으면 당신과 당신의 동료를 위해 일하는 것을 생각해 내십시오. 논리적으로 유지하십시오. '

Aaronaught가 Charles Simonyi 및 헝가리 표기법에 대한 인용을 요청한 이후 : http://en.wikipedia.org/wiki/Charles_Simonyi

http://en.wikipedia.org/wiki/Hungarian_notation

http://msdn.microsoft.com/en-us/library/aa260976(v=VS.60).aspx

http://ootips.org/hungarian-notation.html

http://www.hitmill.com/programming/vb/Hungarian.html

http://web.mst.edu/~cpp/common/hungarian.html

마지막 두 개는 헝가리 표기법의 예일 뿐이며 ootips 링크는 주제에 대한 일부 의견에 대한 인용입니다. 시스템 헝가리어 표기법도 있지만 내가 아는 한 Microsoft 프로그래머가 인기를 얻었습니다 (앱 변형에 대한 Simonyi와 달리, 나는 누구도 알지 못합니다).