VB.NET에서 Dim foo As Foo를 사용하는 데 문제가 있습니까?

Question

최근 VB.NET 프로젝트에서 저는 C#에서 사용하는 명명 규칙을 채택했습니다. 즉, 변수를 참조하는 클래스와 동일한 이름으로 호출하는 경우가 종종 있습니다.

Foo foo = new Foo(); // C# 

Dim foo As New Foo() ' VB.NET 

특히 작은 방법의 경우 코드를 작성하는 것이 가장 명확한 방법입니다. 이 코딩 스타일은 대소 문자를 구분하는 C#에서 잘 작동하며 Visual Studio에서 제공하는 구문 강조로 인해 클래스 이름과 변수 이름이 다른 것을 쉽게 볼 수 있습니다.

그러나 놀랍게도 VB.NET에서는 거의 100 %의 시간이 걸렸습니다. 유일한 문제는 변수 이름이 다중 ID를 사용하는 것처럼 보였습니다. 즉, 인스턴스 메소드와 Foo 클래스의 공유 (정적) 메소드를 호출하는 데 사용될 수 있습니다. 이것은 실제로 문제를 일으키지는 않았지만 Intellisense가 정적 및 인스턴스 메소드를 모두 포함하는 목록을 제공한다는 것을 의미했습니다. 변수 이름 뒤에.

놀랍게도 이것은 실제로 내 프로젝트에서 혼란을 일으키지 않았으며 지금까지 성공했습니다. 그러나 나는이 특별한 프로젝트에서 일하는 유일한 사람이었다. 여기

은 약간 더 예입니다

Dim collection as Collection = New Collection() 
For Each bar As Bar in Bar.All() 
    collection.SomeInstanceMethod(bar) 
Next 
collection.SomeSharedMethod() 

* 나는이 발견 유일한 문제는 때때로 '이름 바꾸기'리팩토링 도구는 클래스 이름을 바꿀 때 즉, 그것은을 가진 변수의 이름을 바꿀 것 혼동하는 것이었고, 선언 선 (Dim foo As...)에는 클래스와 동일한 이름이 있지만 해당 변수에 대한 다른 참조는 없으므로 컴파일러 문제 (duh)가 발생합니다. 이들은 항상 쉽게 고칠 수있었습니다.

또 다른 작은 성가심은 VB.NET 구문 형광펜이 변수 이름보다 다른 클래스 이름을 강조 표시하지 않으므로 C#에서 사용할 때만큼 멋지지 않습니다. 나는 여전히 매우 읽기 쉬운 코드를 발견했다.

다른 누구나 팀 환경에서 허용 했나요? VB.NET에서이 명명 규칙에 다른 잠재적 인 문제가 있습니까?

Answer 1

여기 나머지 답변과는 차이가있을 것입니다.이 작업을 수행하는 데 문제가 있다고 생각하지 않습니다. 나는 그것을 정기적으로하고, 그것으로부터 발생하는 0 가지 문제를 절대적으로 가지고있다.

변수 이름에 소문자를 사용하면 변수를 유형과 쉽게 구별 할 수 있으며 컴파일러는 두 식별자를 혼동하지 않습니다.

변수 선언을 삭제하면 컴파일러에서이 변수에 대한 다른 참조가 이제 해당 유형을 참조한다고 생각하지만 오류로 태그 지정되므로 실제로 문제가되지 않습니다.

Answer 2

VB.NET은 대소 문자를 구분하지 않습니다! 우리가 사용하는 것이 우리 팀 환경에서 표준으로

Foo Foo = new Foo(); // C# 

:이 동일합니다

Dim oFoo as New Foo 'VB.NET 

Answer 3

VB는 대소 문자를 구분하지만, 컴파일러는 객체 인스턴스 사이에 혼동하지 않도록 충분히 지능 그리고 그 수업.

그러나 대소 문자를 구별하지 않는 언어로 같은 이름을 사용하는 것은 매우 위험하고 잘못되었습니다. 특히 다른 프로그래머가 해당 프로젝트를 작업하는 경우.

Answer 4

나는 VB와 C# 사이를왔다 갔다해야한다. 우리는 C#의 변수 이름이 대소 문자에 따라 다르다는 점도 싫어합니다. 대신 _ 접두사를 사용하거나보다 의미있는 이름을 지정합니다.

새로운 언어를 시작할 때마다 필연적 인 일들을하는 방식이 다르다는 것을 알게 될 것입니다. 종종 이것은 동일한 문제를 해결하는 다른 언어의 다른 기능을 처음에는 인식하지 못했기 때문입니다.VB를 처음 사용하기 때문에 다음과 같은 몇 가지 메모를 통해 작업을 완료하는 데 도움이됩니다.

VB.Net이 대소 문자를 구분하지 않는 것은 100 % 정확하지 않습니다. 케이스 - 대응. 변수를 식별자로 선언하면 IDE는 어떤 사례를 사용했는지 메모하고 다른 용도로 자동 대치하여 해당 사례를 일치시킵니다. 이 기능을 사용하면 IDE에서 변수 또는 유형에 대해 혼란 스러울 수있는 오타 나 장소를 발견 할 수 있습니다. 실제로 실제로 대소 문자를 구분하는 방식을 선호합니다.

VB.Net은 네임 스페이스를 다르게 가져옵니다. File 클래스를 사용하려면 System.IO을 맨 위에 가져 오지 않고 IO.File이라고 말하면됩니다. 이 기능은 특히 API의 최상위 섹션을 가져 와서 다음 네임 스페이스 이름을 입력 할 수 있기 때문에 중첩 된 네임 스페이스 레이어가있는 새 API를 배울 때 유용합니다. 그러면 다음 네임 스페이스 이름을 입력하면 해당 네임 스페이스의 클래스 목록이 표시됩니다 . 여기에서 설명하기는 어렵지만, C#으로 돌아 가면 찾아보고 사용하기 시작합니다. 가장 중요한 것은 필자가 최소한 하나 또는 두 번 사용할 수있는 네임 스페이스에 대한 또 다른 지시문을 추가하기 위해 파일의 맨 위로 이동해야한다는 것을 알기 위해서입니다. VB에서는 인터럽트가 훨씬 덜 일반적입니다.

VB.Net은 백그라운드 컴파일을 수행합니다. 커서가 라인을 떠나는 순간, 은을 알고 있습니다. 라인이 컴파일되는지의 여부. 이것은 다소 클래스 이름을 강조 표시하지 않습니다. 이유는 C#에서 유용한 이유 중 일부는 올바르게 입력했기 때문입니다. VB.Net은 이와 관련하여 귀하에게 더욱 확신을줍니다.

Answer 5

Moayad가 지적했듯이 컴파일러는 차이점을 알 수 있지만 유지 관리 문제 및 기타 부작용을 초래할 수있는 나쁜 습관입니다.

더 나은 방법은 유형 이름이 아니라 사용중인 컨텍스트에서 변수의 이름을 지정하는 것입니다. 이로 인해 자체 문서화 코드가 생기고 적은 수의 주석이 필요합니다 (주석은 밀도가 높은 코드를 작성하는 핑계로 남용됩니다).

Answer 6

나는 과거에도 같은 일을했다. Visual Studio가 자동으로 코드를 포맷하고 정적 메서드의 대소 문자를 소문자로 변경하면 때때로 Visual Studio가 혼란스러워하기 때문에 여기서 벗어나기 시작했습니다. 변수 및 클래스 이름을 대소 문자로만 구분할 수없는 것보다 훨씬 성가시다. 그러나 기술적 인 관점에서 보면 문제가 발생하지 않아야합니다.

Answer 7

컴파일러가 항상 Foo이 클래스 또는 변수를 의미하는지 여부를 판단 할 수있는 경우에만 안전합니다. 결국은 사용자가 지정할 수없는 경우를 치게됩니다. 에릭 리 퍼트 (Eric Lippert)가 잘못 갈 수있는 일에 대해 이야기합니다. on his blog.

Answer 8

글쎄, 이것이 최종 답변이 아니며 확실한 결정이 있다고 생각하지 않지만 일반적인 명명 규칙은이 명명 규칙을 사용하는 것이 좋지 않은 것 같습니다. 좋은 VB.NET 변수 이름을 작성하는 진정한 방법이 있어야하며, 대안을 좋아하지 않습니다 ...

다음은이 특정 질문을 다루지 않는 것 같지만 관심있는 모든 사람을위한 공식 Microsoft 가이드 라인 링크입니다 (놓친 경우 수정하십시오).

Visual Basic의 명명 규칙 : http://msdn.microsoft.com/en-us/library/0b283bse.aspx

선언 요소 이름 : http://msdn.microsoft.com/en-us/library/81ed9a62.aspx

건배 모두를!

Answer 9

나는 항상이 규칙을 사용하고 있으며 결코 문제가되지 않습니다. 변수의 가장 자연스러운 이름은 종종 클래스 이름이기 때문에 호출해야합니다 (임의의 Line? 행에 대한 최상 이름).

유일한 단점은 일부 도구가 컨텍스트를 잘못 해석 할 때입니다. 예를 들어, Visual Studio 2010 베타 1은 클래스와 동일한 이름의 변수에 대해 클래스 강조 표시를 사용하는 경우가 있습니다. 그건 좀 짜증나.

상황 감도는 대소 문자를 구분하는 것보다 훨씬 가깝습니다.