변수 명명 규칙? [닫은]

방금 ReSharper (C # 용)를 사용하기 시작했으며 코드 냄새 탐지기와 비슷합니다. 오래 전에 수정해야 할 작문 (주로 가변 명명 규칙)을 보여줍니다.

메소드 및 인스턴스 변수에 대한 일부 명명 규칙을 다시 생각하게했습니다. ReSharper는 인스턴스 변수가 낮은 낙타의 경우 밑줄로 시작하도록 제안합니다. 잠시 동안 나는 모든 지역 변수를 낙타의 경우로 만들려고했지만 밑줄이 필요합니까? 편안하다고 생각하십니까? 나는이 컨벤션이 마음에 들지 않지만 아직 시도하지도 않았습니다. 당신은 그것에 대해 어떻게 생각하십니까?

두 번째로 재평가하라는 메시지는 GUI 이벤트 핸들러에 대한 명명 규칙입니다. 나는 보통 VS 표준 ControlName_Action의 VS 표준을 사용하고 컨트롤은 일반적으로 헝가리어 표기법 (접미사로 사용자가 볼 수있는 것과 비슷한 이름의 변수를 처리 할 때 보이지 않는 것을 코드에서 명확히하는 데 도움이 됨)을 사용하므로 OK_btn_Click ( ), 당신의 의견은 무엇입니까? ReSharper 규칙에 따라야합니까 아니면 다른 유효한 옵션이 있습니까?

사용하는 명명 규칙 체계를 사용하도록 ReSharper를 수정할 수 있습니다. 이벤트 핸들러, 필드, 속성, 다양한 접근성 수준을 가진 메소드 등을 사용자 정의하는 것을 포함하여 매우 유연합니다.

도구가 표준을 정의하게하지 마십시오. 표준을 사용하여 표준을 시행하십시오.

업데이트 : 직장에서 우리는 변수, 필드 및 인수와 같은 대부분의 사적인 것들에 주로 낙타 사건을 주로 사용한다고 말했습니다. 메서드 이름, 상수 및 속성에 대한 대문자 낙타 경우. 이벤트 핸들러는 컨트롤에 특정한 것이 아니라 자신이 나타내는 액션에 따라 이름이 지정됩니다 (예 : HandleContinueButtonClick이 아닌 HandleCustomerContinue). ReSharper 기본 구성표를 잠시 동안 사용해 보았지만 실제로는 신경 쓰지 않습니다.

에 관하여

그러나 밑줄이 필요합니까? 편안하다고 생각하십니까?

밑줄 사용에 대해 내가 가장 좋아하는 것은 "this"의 사용을 크게 줄인다는 것입니다.

치다:

public void Invoke(int size) {
    _size = size;
}

밑줄이 없으면 다음과 같이 작성해야합니다.

public void Invoke(int size) {
    this.size = size;
}

잠재적으로 다음과 같은 미묘한 오류가 발생합니다.

public void Invoke(int size) {
    size = size;    // urgh ... no this! 
}

또한 밑줄 만 입력하면 개인 필드 만 나열되고 "this"를 사용하면 모든 목록이 표시되므로 코드 완성이 더 깨끗해집니다.

에 관하여

일반적으로 헝가리어 표기법을 사용합니다

프레임 워크 디자인 가이드 라인 : 재사용 가능한 .NET 라이브러리의 규칙, 아이 돔 및 패턴은 다음과 같이 말합니다.

헝가리어 표기법을 사용 하지 마십시오

모호성을위한 작은 공간을 떠나기 :)

일관성은 실제로 핵심입니다. 명확하고 명확합니다. 즉, 비밀을 유지하거나 모든 것을 줄여서 타이핑을 저장하려고하지 마십시오. Intellisense는 암호가 아닌 짧은 이름이 아닌 타이핑 보호기입니다.

C #에서 밑줄로 보호 또는 공개 이름을 시작하면 공용 언어 사양에 위배됩니다. 개인 회원의 경우에만 정확합니다.

MSDN에서 :

구현 된 언어에 관계없이 다른 객체와 완전히 상호 작용하려면 객체는 상호 운용해야하는 모든 언어에 공통적 인 기능 만 호출자에게 노출해야합니다. 이러한 이유로 많은 응용 프로그램에 필요한 기본 언어 기능 집합 인 CLS (Common Language Specification)가 정의되었습니다.

참조 : http://msdn.microsoft.com/en-us/library/12a7a7h3.aspx

밑줄에 대한 경고를 읽을 수 있습니다.

밑줄 (_)로 시작하는 요소 이름은 CLS (Common Language Specification)의 일부가 아니므로 CLS 호환 코드는 해당 이름을 정의하는 구성 요소를 사용할 수 없습니다. 그러나 요소 이름의 다른 위치에있는 밑줄은 CLS 규격입니다.

참조 : http://msdn.microsoft.com/en-us/library/81ed9a62.aspx

보호 된 회원은 다른 언어로 작성된 수업에서 상속받을 수 있기 때문에 문제가됩니다.

그러나 CLS 컴파일러 코드가 필요하지 않은 경우에는 문제가되지 않을 수 있습니다.

나는 밑줄을 좋아한다. 언뜻 보면 변수가 클래스 멤버이고 개인이라는 것을 알 수 있습니다.

IDE가 마우스를 가져 가면 "첫눈에"이길 수 없다고 말할 수 있습니다. 지역 변수가 무엇인지, 눈만으로 멤버 변수가 무엇인지 알고 있습니다. 스크롤이나 마우스 호버가 필요하지 않습니다.

"this"키워드를 사용할 수 있지만 수평 스캔 성을 높이려면 _가 짧습니다. 설명적인 이름이 일반적으로 바람직하지만 어떤 것이 확립 된 규칙 일 때는 1 개의 문자를 사용하는 것이 좋습니다. 예를 들어 배열을 반복 할 때 문자 i를 색인으로 사용합니다. i가 인덱스라는 확립 된 규칙이므로 "i"의 의미를 궁금해하지 않으면 서 스캔 가능성을 얻을 수 있습니다.

나는 일반적으로 다른 사람들의 말에 동의하지만 도구와 도구 체인에 관해서는 게으르고 쉬운 삶과 같습니다. 나는 종종 그들이 제안한 방식대로 생활하는 것이 더 쉽다는 것을 안다. 이유는

• 설치가 더 쉽습니다 (기본값으로 이동하십시오 .Enter 키를 20 번 눌러도 가능합니다)
• 버그는 일반적으로 기본 설정, 종종 결함을 처음으로 노출시키는 난해한 구성으로 해결되었습니다.
• 툴 체인 공급 업체는 아마도 나보다 더 많은 것을 알고있을 것입니다. 전문가를 잘못 결정하는 사람은 누구입니까 (도구를 구입했기 때문에 전문가라고 생각합니다)
• 관리자가 공급 업체 선택을 방어 할 필요는 없습니다. "추천합니다"
• 새로운 사람은 "왜"와 "그것은 더 나은 방법"으로 당신을 버그하지 않습니다-모든 대답은 "그들이 결정했기 때문에 ..."

따라서 방금 방금 투자 한 도구를 재구성 해야하는 정당한 이유를 찾을 수 있다면 내가 할 것입니다. 변경을 정당화 할 수 없다면하지 마십시오.

각각의 모든 변경에는 유지하기 위해 지속적인 비용 (실제 및 숨김)이 있습니다. 비용이 적을수록 비용이 줄어 듭니다. 예를 들어, 내가 언급 한 새로운 사람은 아무런 변화가 없다는 것은 매뉴얼을 읽을 수 있다는 것을 의미합니다. 재구성-부록을 작성하고, otehr 물건과 함께 보관하고, 폐기하고 매뉴얼을 읽은 후 읽도록해야합니다. 2 인용 상점에는 문제가 없지만 100 인용 상점은 어떻습니까?

당신이 묻는 두 가지 규칙, 개인 필드 이름의 시작 부분에서 밑줄, 메소드 이름은 일반적으로 C # 개발 서클의 표준으로 간주됩니다. 이러한 규칙에 적응함으로써 코드는 다른 개발자들에게보다 이해하기 쉬워 질 것입니다. 왜냐하면 그것은 그것이 작동하는 데 사용되는 마음의 틀이기 때문입니다.

컨트롤의 Label, RadioButton 등의 접미사는 일반적으로 표준으로 간주됩니다. 단일 개념 (예 : Label 및 TextBox)에 대해 여러 개의 컨트롤이 존재하는 경우가 많으며이 접미사는 매우 유용합니다. 진정한 헝가리어 표기법 은 원래 의도를 표현하지 않는 무언가로 개화되어 있기 때문에 오래 전에 포기되었습니다.

필자의 경우 낙타와 밑줄을 사용하면 설명 적 (읽기 : 긴) 변수 이름과 코드 완성에 도움이됩니다. Visual Studio 자동 완성 기능이 어떻게 작동하는지 잘 모르겠지만 QtCreator에서 이클립스와 같이 덜 입력 할 수 있습니다.

sDI

그리고 그것을 확장했다

someDescriptiveIdentifier

다음과 같은 이름이있는 경우 입력을 조금 저장합니다

someDescriptiveName, someOtherDescriptiveName, someOtherButNotTheSameDescriptiveName

"설명 명명 모드"에있을 때 생성하는 경향이 있습니다.

밑줄을 사용하여 자동 완성 할 이름을 결정할 수 있습니다.

someDescriptiveIdentifier

또는

_someDescriptiveClassMember

내 설명이 충분히 명확하기를 바랍니다 :)