Есть ли проблемы с использованием Dim foo As Foo в VB.NET?

Question

В недавнем проекте VB.NET я принял соглашения об именах, которые я привык использовать в C #. А именно, часто вызывая переменную с тем же именем, что и класс, на который она ссылается, только с другим регистром, например

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

Dim foo As New Foo() ' VB.NET

Я считаю, что часто это самый простой способ написания кода, особенно для небольших методов. Этот стиль кодирования, очевидно, прекрасно работает в C #, поскольку он чувствителен к регистру, и из-за подсветки синтаксиса, предоставляемой Visual Studio, очень легко увидеть, что имя класса и имя переменной различаются.

Однако, к моему удивлению, это также нормально работало почти в 100% случаев * в VB.NET. Единственная проблема заключалась в том, что имя переменной, по-видимому, принимало множественную идентичность. А именно, его можно использовать как для вызова методов экземпляра, так и для общих (статических) методов класса Foo. Это на самом деле не вызывало никаких проблем, это просто означало, что Intellisense предоставит список, содержащий как статические методы, так и методы экземпляра после того, как вы нажмете «.» после имени переменной.

Я снова обнаружил, к моему удивлению, что это на самом деле не привело к путанице в моем проекте, и пока он очень успешен! Однако я был единственным, кто работал над этим конкретным проектом.

Вот немного более длинный пример:

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

* Единственная проблема, с которой я столкнулся, заключалась в том, что иногда инструмент рефакторинга 'Rename' путался, т. Е. При переименовании класса он переименовывал переменные с тем же именем, что и у класса, в их строки объявления (Dim foo As...), но не другие ссылки на эту переменную, вызывающие проблемы компилятора (дух). Их всегда было легко исправить.

Еще одно небольшое неудобство заключается в том, что средство подсветки синтаксиса VB.NET не выделяет имена классов иначе, чем имена переменных, что делает его не таким приятным, как при использовании его в C #. Я все еще нашел код очень читабельным, хотя.

Кто-нибудь еще пытался разрешить это в командной среде? Существуют ли другие потенциальные проблемы с этим соглашением об именах в VB.NET?

Answer 1

Хотя VB нечувствителен к регистру, компилятор достаточно умен, чтобы не путать объект-экземпляр с классом.

Однако, безусловно, очень опасно и неправильно использовать одно и то же имя на языке без учета регистра! Особенно, если над этим проектом работают другие программисты.

Answer 2

Я должен перемещаться между VB и C #, и мы считаем это плохой практикой. Мы также не хотим, чтобы имена переменных в C # отличались от их типа только регистром. Вместо этого мы используем префикс _ или даем ему более осмысленное имя.

Всякий раз, когда вы начинаете новый язык, это неизбежно, вы замечаете кучу вещей, которые отличаются, и упускаете старый способ делать вещи. Часто это происходит потому, что вы изначально не знаете о различных функциях на другом языке, которые решают ту же проблему. Поскольку вы новичок в VB, вот пара замечаний, которые помогут вам добиться цели:

Не на 100% правильно утверждать, что VB.Net нечувствителен к регистру, если только вы не подчеркнули, что он учитывает регистр . Когда вы объявляете идентификатор variable , IDE запоминает, какой случай вы использовали, и автоматически исправляет другие варианты использования, чтобы соответствовать этому случаю. Вы можете использовать эту функцию, чтобы помочь обнаружить опечатки или места, где в среде IDE может возникнуть путаница с переменной или типом. Я действительно предпочел это реальным схемам, чувствительным к регистру.

VB.Net импортирует пространства имен по-разному. Если вы хотите использовать класс File, вы можете просто сказать IO.File без необходимости импортировать System.IO вверху. Эта функция особенно полезна при изучении нового API с несколькими вложенными слоями пространства имен, поскольку вы можете импортировать раздел API верхнего уровня, ввести имя следующего пространства имен, и вам будет предложен список классов в этом пространстве имен. , Здесь это сложно объяснить, но если вы посмотрите на это и начнете его использовать, вы действительно упустите его, когда вернетесь к C #. Главное, что, по крайней мере для меня, это действительно нарушает мой поток, и мне необходимо перейти к началу файла, чтобы добавить еще одну директиву using для пространства имен, которое я могу использовать только один или два раза. В VB такое прерывание встречается гораздо реже.

VB.Net выполняет фоновую компиляцию. В тот момент, когда ваш курсор покидает строку, вы знаете , компилируется ли эта строка или нет. Это в некоторой степени компенсирует отсутствие выделения имен классов, потому что отчасти это полезно в C #, так что вы знаете, что набрали его правильно. VB.Net дает вам еще большую уверенность в этом отношении.

Answer 3

Я собираюсь расходиться с остальными ответами здесь ... Я не думаю, что есть какие-либо проблемы с этим. Я делаю это регулярно, и у меня абсолютно 0 проблем.

Если вы используете строчную букву для имени переменной, вы можете легко отличить переменную от типа, и компилятор не перепутает два идентификатора.

Если вы удалите объявление переменной, компилятор подумает, что другие ссылки на эту переменную теперь ссылаются на тип, но это не является проблемой, поскольку они будут помечены как ошибки.

Answer 4

Я делал то же самое в прошлом. Я начинаю отходить от этого, потому что Visual Studio иногда запутывается, когда он автоматически форматирует код и меняет регистр в моих статических вызовах методов на строчные. Это еще более раздражает, чем отсутствие возможности различать имена переменных и классов только по регистру. Но чисто с технической точки зрения это не должно вызывать каких-либо проблем.

Answer 5

Я использую это соглашение все время, и это никогда не было проблемой. Наиболее естественным именем переменной часто является имя класса, и поэтому его следует называть (Лучшее имя для произвольной строки? Line.).

Единственный недостаток - когда какой-то инструмент неправильно интерпретирует контекст. Например, Visual Studio 2010 beta 1 иногда использует подсветку класса для переменных, названных так же, как и класс. Это немного раздражает.

Чувствительность к контексту намного ближе к тому, как я думаю, чем чувствительность к регистру.

Answer 6

Это безопасно только до тех пор, пока компилятор всегда может сказать, означает ли Foo класс или переменную, и в конечном итоге вы попадете в ситуацию, когда это невозможно. Эрик Липперт обсуждает то, что может пойти не так в своем блоге .

Answer 7

Как отмечает Моаяд, компилятор может заметить разницу - но это плохая практика, которая может привести к проблемам с обслуживанием и другим побочным эффектам.

Лучшей практикой является попытка назвать переменную в контексте, который они используют, а не просто имя типа. Это приводит к самодокументируемому коду и требует меньшего количества комментариев (комментарии используются как предлог для написания плотного кода).

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

VB.NET не чувствителен к регистру! Это соответствует:

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

В качестве стандарта в нашей командной среде мы будем использовать:

Dim oFoo as New Foo 'VB.NET