VB.NET 비공개 필드의 명명 규칙

StackOverflow https://stackoverflow.com/questions/7642

  •  08-06-2019
  •  | 
  •  

문제

VB.NET에서 개인 필드 이름을 지정하는 공식 규칙이 있습니까?예를 들어 'Foo'라는 속성이 있는 경우 일반적으로 비공개 필드를 '_Foo'라고 부릅니다.이것은 눈살을 찌푸리는 것 같습니다. 공식 지침:

"필드 이름에 접두사를 사용하지 마십시오.예를 들어, 정적 필드와 비정적 필드를 구별하기 위해 g_ 또는 s_를 사용하지 마십시오.

C#에서는 프라이빗 필드 'foo', 속성 'Foo'를 호출하고 생성자에서 프라이빗 필드를 'this.foo'로 참조할 수 있습니다.VB.NET은 대소문자를 구분하지 않으므로 이 작업을 수행할 수 없습니다. 어떤 제안이 있습니까?

도움이 되었습니까?

해결책

저는 여전히 VB에서 개인 필드에 _ 접두어를 사용하므로 개인 필드로 _foo를, 속성으로 Foo를 사용하겠습니다.나는 C#과 내가 작성하는 거의 모든 코드에 대해 이 작업을 수행합니다.일반적으로 나는 "올바른" 방법이 무엇인지에 너무 집착하지 않을 것입니다. 왜냐하면 실제로는 "올바른" 방법이 없기 때문입니다(매우 나쁜 방법도 있지만). 오히려 일관되게 수행하는 데 관심이 있습니다.

결국 일관성을 유지하면 "올바른" 규칙을 사용하는 것보다 코드를 훨씬 더 읽기 쉽고 유지 관리하기 쉽게 만들 수 있습니다.

다른 팁

개인 취향이기는 하지만 폭넓은 지지를 받고 있습니다. 일부 구별.C#에서도 널리 사용되는 규칙이 하나도 없다고 생각합니다.

제프 프로시스 라고

개인적 선호에 따라 나는 일반적으로 비공개 필드 앞에 밑줄([C#에서])을 붙입니다.이 규칙은 .NET 프레임워크에서 꽤 많이 사용되지만 전체적으로는 사용되지 않습니다.

로부터 .NET Framework 디자인 지침 2판 73쪽.

제프리 리히터 라고

모든 필드를 비공개로 설정하고 인스턴스 필드 앞에 "m_"을 붙이고 정적 필드에는 "s_" 접두사를 붙입니다. [C#]

로부터 .NET Framework 디자인 지침 2판 47쪽.앤서니 무어(BCL팀) 또한 "m_"과 "s_"를 사용하는 것이 고려할 가치가 있다고 생각합니다(48페이지).

공식 지침은 바로 지침입니다.당신은 항상 그들 주위를 돌아 다닐 수 있습니다.즉, 우리는 일반적으로 필드 앞에 밑줄을 붙입니다. 둘 다 C# 및 VB.NET.이 규칙은 매우 일반적입니다(그리고 분명히 공식 지침은 무시됩니다).

그런 다음 "me" 키워드 없이 비공개 필드를 참조할 수 있습니다("this" 키워드는 C#용입니다. :)

구체적으로 연결한 디자인 지침에는 정적 공개 및 보호 필드에만 적용된다고 명시되어 있습니다.디자인 지침은 대부분 공개 API 디자인에 중점을 둡니다.비공개 멤버로 무엇을 하느냐는 전적으로 귀하에게 달려 있습니다.긍정적이지는 않지만 컴파일러가 CLS 준수 여부를 확인할 때 전용 멤버는 고려되지 않는다는 점을 상대적으로 확신합니다. 왜냐하면 공용/보호 멤버만 거기에 참여하기 때문입니다(아이디어는 "만약 다음과 같은 언어를 사용하는 사람이 _ 캐릭터가 라이브러리를 사용하려고 시도하는 것을 허용하지 않습니까?" 멤버가 비공개인 경우 대답은 "아무것도 아닙니다. 사용자는 이 멤버를 사용할 필요가 없습니다."이지만 멤버가 공개인 경우 문제가 발생합니다. )

즉, 저는 반향실에 추가하여 무엇을 하든 일관성을 유지하는 것이 중요하다는 점을 지적하겠습니다.내 고용주는 C#과 VB 모두에서 개인 필드 앞에 _를 붙일 것을 요구하고 있으며, 우리 모두는 이 규칙을 따르기 때문에 다른 사람이 작성한 코드를 사용하기 쉽습니다.

VB.NET 4.0에서는 다음과 같이 Property 선언에 대해 getter 및 setter를 명시적으로 작성할 필요가 없다는 사실을 대부분 알고 계실 것입니다.

Public Property Foo As String
Public Property Foo2 As String

VB는 _Foo 및 _Foo2라는 전용 멤버 변수를 자동으로 생성합니다.Microsoft와 VS 팀이 _ 규칙을 채택한 것 같으므로 이에 대한 문제는 없습니다.

공식적인 명명 규칙은 없는 것 같지만 Microsoft가 Microsoft.VisualBasic dll(리플렉터를 통해)에서 m_을 사용하는 것을 보았습니다.

나는 여전히 개인 필드의 경우 vb의 _ 접두사를 사용하므로 _foo를 개인 필드로, foo는 속성으로 제공 할 것입니다.나는 c#과 내가 쓴 거의 모든 코드를 위해 이것을한다.일반적으로 나는 "올바른"방법이 없기 때문에 "올바른 방법이 무엇인지"에 너무 빠지지 않을 것입니다 (매우 나쁜 방법이 있습니다).

명확성과 일관성을 위해 "_"보다 더 나은 것을 찾지 못했습니다.단점은 다음과 같습니다:

나는 편집기에서 해당 기능을 꺼서 선을 피하고 CLS 준수에 대해 너무 많이 생각하지 않으려고 노력합니다.

@lomaxx의 의견에 동의합니다. 팀 전체에서 일관성을 유지하는 것이 더 중요합니다. 오른쪽 협약.

그럼에도 불구하고 코딩 규칙에 대한 아이디어와 지침을 얻을 수 있는 몇 가지 좋은 장소는 다음과 같습니다.

  1. Microsoft Visual Basic 및 Visual C#에 대한 실제 지침 및 모범 사례 Francesco Balena의 개발자는 이러한 문제 중 많은 부분을 다루는 훌륭한 책입니다.
  2. IDesign 코딩 표준 (C# 및 WCF의 경우)
  3. .NET 프레임워크 소스 코드 (VS2008에서)

나는 개인 필드에 밑줄 접두어를 사용하는 것을 선호합니다.메소드 매개변수에는 첫 글자를 소문자로 사용합니다.나는 메소드에 대해 소문자 카멜케이스 매개변수를 갖는 지침을 따릅니다. 이는 클래스용 API의 일부이기 때문에 비공개 필드의 이름 지정보다 더 중요하다고 생각합니다..예를 들어

Public Class Class1

    Private _foo As String
    Public Property Foo() As String
        Get
            Return _foo
        End Get
        Set(ByVal value As String)
            _foo = value
        End Set
    End Property

    Public Sub New(ByVal foo As String)
        _foo = foo
    End Sub

End Class

이 패턴을 사용하면 C# 또는 VB.NET에서 private 필드 및 생성자 매개 변수와 이름 지정 충돌이 발생하지 않습니다.

가장 중요한 것은 어떤 스타일을 사용하느냐가 아니라 일관성을 유지하는 것이라는 점에 동의합니다.

즉, 비공개 필드에 대한 새로운 MS/.NET 스타일은 _fooVar(밑줄 뒤에 CamelCased 이름이 옴)인 경향이 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top