Я не пытаюсь начинать здесь спор, но по какой-то причине обычно утверждается, что Visual Basic нечувствителен к регистру, а языки C - нет (и почему-то это хорошо).
Но вот мой вопрос: где именно Visual Basic нечувствителен к регистру? Когда я печатаю ...
Dim ss As String
Dim SS As String
... в интегрированной среде разработки Visual Studio 2008 или Visual Studio 2010 у второго появляется предупреждение " Локальная переменная SS
уже объявлена в текущем блоке ». В VBA VBE он не сразу выдает ошибку, а просто автоматически исправляет случай.
Я что-то упускаю из-за этого аргумента, что Visual Basic не чувствителен к регистру? (Кроме того, если вы знаете или хотите ответить, почему это должно быть плохо?)
Почему я вообще задаю этот вопрос?
Я уже много лет использую Visual Basic во многих его диалектах, иногда как любитель, иногда для программ малого бизнеса в рабочей группе. Последние шесть месяцев я работал над большим проектом, намного большим, чем я ожидал. Большая часть примеров исходного кода написана на C #. У меня нет горячего желания изучать C #, но если есть вещи, которые я упускаю из того, что предлагает C #, чего нет в Visual Basic (напротив, VB.NET предлагает XML-литералы ), тогда я бы хотел чтобы узнать больше об этой функции. В этом случае часто утверждают, что языки C чувствительны к регистру и это хорошо, а Visual Basic нечувствителен к регистру, а это плохо. Я хотел бы знать...
- Насколько точно Visual Basic нечувствителен к регистру, поскольку каждый пример в редакторе кода становится чувствительным к регистру (то есть регистр исправляется), хочу я этого или нет.
- Достаточно ли это убедительно для меня, чтобы подумать о переходе на C #, если случай VB.NET каким-то образом ограничивает то, что я могу делать с кодом?
источник
SS
иss
в VB, что бы я ни использовал первым, это тот, который использует редактор.Ответы:
Разница между VBA и VB.NET заключается только в том, что VB.NET постоянно компилируется в фоновом режиме. Вы получите сообщение об ошибке при компиляции VBA.
Как говорит Джонатан , при программировании вы можете думать о VB.NET как о нечувствительности к регистру, кроме сравнения строк, XML и некоторых других ситуаций ...
Я думаю, вам интересно, что находится под капотом. Что ж, .NET Common Language Runtime чувствителен к регистру , а код VB.NET полагается на среду исполнения, поэтому вы можете видеть, что он должен быть чувствительным к регистру во время выполнения, например, когда он ищет переменные и методы.
Компилятор и редактор VB.NET позволяют вам игнорировать это, потому что они исправляют регистр в вашем коде.
Если вы поиграете с динамическими функциями или поздним связыванием (Option Strict Off), вы можете доказать, что базовая среда выполнения чувствительна к регистру. Другой способ убедиться в этом - понять, что языки с учетом регистра, такие как C #, используют одну и ту же среду выполнения, поэтому среда выполнения, очевидно, поддерживает чувствительность к регистру.
РЕДАКТИРОВАТЬ Если вы хотите исключить IDE из уравнения, вы всегда можете выполнить компиляцию из командной строки . Измените код в Блокноте , так что есть
ss
иSS
увидеть , что делает компилятор.ИЗМЕНИТЬ цитату Джеффри Рихтера на странице 45 рекомендаций по проектированию .NET Framework .
источник
ss
и,SS
и он будет компилироваться и работать, как ожидалось?Dim pdfWriter As PDFWriter
полностью действителен. VB.NET позволяет вам различать имена классов и имена переменных, что приятно, поскольку это обычная практика для языков, полностью чувствительных к регистру.Отчасти проблема здесь в том, что вам нужно отделить язык от опыта IDE.
Как язык, VB.NET , безусловно, нечувствителен к регистру идентификаторов. Вызов
DateTime.Parse
иdatetime.parse
будет привязан к одному и тому же коду. И в отличие от таких языков, как C #, невозможно определить методы или типы, которые отличаются только регистром.В качестве IDE VB.NET пытается сохранить регистр существующих идентификаторов, когда он довольно перечисляет блок кода. Красивые списки появляются всякий раз, когда вы уходите от текущей логической строки кода. В этом случае вы переходите от второго объявления
SS
, симпатичный листер замечает, что существует идентификатор с этим именем, и исправляет его, чтобы он соответствовал регистру.Это поведение, тем не менее, выполняется исключительно как добавленная пользователем ценность. Это не часть основного языка.
источник
ss
идентичноSS
, но и в качестве вспомогательного средства для чтения IDE исправляют ,SS
чтобыss
при вводе текста. Таким образом, даже если IDE не исправит регистр, компилятор все равно будет рассматривать два идентификатора как идентичные.VB в основном нечувствителен к регистру, но есть исключения. Например, литералы и понимание XML чувствительны к регистру. Сравнение строк обычно чувствительно к регистру, в отличие, скажем, от T-SQL, но есть переключатель компилятора, который делает сравнение строк нечувствительным к регистру. И, конечно же, есть крайние случаи, когда речь идет о наследовании, COM и динамической среде выполнения.
источник
Dim mi as mailitem
иsubject = mi.subject
, имена объектов будут автоматически исправлены наMailItem
иmi.Subject
. Это заботит компилятор (потому что он всегда автоматически исправляет это), или это красивый код, или ...?Да, компилятор VB.NET обрабатывает идентификаторы без учета регистра. И да, это может вызвать проблемы, когда он использует сборки, написанные на другом языке, или использует компоненты COM. Первый случай рассматривается в Спецификации общего языка . Соответствующее правило:
Конструктор библиотек типов позаботился о случае COM довольно грубо, он заставляет совпадать регистр идентификаторов с одинаковыми именами. Даже если у этих идентификаторов разные роли. Другими словами, параметр метода с именем «index» заставит имя метода «Index» преобразоваться в «index». Как вы могли догадаться, это вызвало довольно много головной боли :)
источник
VB сохраняет регистр (в среде IDE), но нечувствителен к регистру . В некотором смысле это похоже на файловую систему Windows. Считается, что файлы Hello.txt и hello.txt имеют одно и то же имя.
IDE предполагает, что объявление переменной является «правильным» случаем для этой переменной, и корректирует каждый экземпляр этой переменной, соответствующий объявлению. Это делается из соображений привлекательности и последовательности, но не из соображений функциональности.
Я видел несколько случаев, когда регистр не был автоматически изменен в соответствии с объявлением, и оператор работает точно так же. Вы также можете использовать любой текстовый редактор для написания кода, который будет отлично компилироваться в разных случаях.
Примечание:
Большинство PEOPLE думать регистронезависимом образом. Когда мы видим слово «собака», это слово приобретает значение в нашем сознании. Значение слова не зависит от регистра (т.е. независимо от того, по буквам оно «СОБАКА», «ДОГ» или «СОБАКА» по-прежнему лает.) КОМПЬЮТЕРЫ рассматривают слова как отдельные мешки битов. Прописные и строчные буквы - это разные битовые шаблоны и, следовательно, разные.
Поскольку большинство программистов - люди, нечувствительность к регистру кажется более адаптированной к тому, как люди думают, а чувствительность к регистру больше связана с тем, что люди приспосабливают свой образ мышления к ограничениям машины.
источник
object.method()
иObject.Method()
мгновенно распознаются как ссылки и методы на объекты и классы (если вы соответствуете этому соглашению о кодировании). Как и в английском языке, вы различаете имена собственные и начало предложений с заглавной буквы. Поэтому при чтении или программировании я не думаю, что регистр нечувствителен, иначе я бы упустил какой-то смысл.form
иForm
то же самое, что меня в любом случае сбивает с толку. В случае (извините еще раз), изtemp
иTemp
вы можете легко использовать инструменты рефакторинга в C # переименоватьTemp
вbobTemp
или любой другой . Тем не менее, я поддерживаю некоторый VB, и кто-то пошел и сделалDim form As Form
. Теперь, когда я переименовываю, он переименовывает ссылки на классы и объекты. Bleah!Это часть используемого вами редактора, они могут вести себя по-разному, но факт в том, что Visual Basic действительно нечувствителен к регистру. Итак,
ss
иSS
такие же.Пожалуйста, посмотрите учебник по основам VB.NET для получения дополнительной информации :)
источник
Я не уверен, что понимаю тебя? VB нечувствителен к регистру, поэтому ss и SS - это одна и та же переменная, поэтому компилятор правильно жалуется, что вы повторно объявили переменную.
Я думаю, что переменные не чувствительны к регистру, но имена функций чувствительны.
источник
ss
а затем набираюSS
, он автоматически корректируетсяss
, что заставляет меня думать, что компилятор действительно заботится о регистре.Да, VB не чувствителен к регистру. Иногда это заставляет тех, кто к этому не привык, зацикливаться.
источник
Не нужно изо всех сил пытаться в VB.NET создать код с разными прописными и строчными буквами "написания" идентификатора. Изменение регистра идентификатора в файле, в котором он объявлен, без использования функции «Переименовать» не приведет к обновлению имени в других файлах, хотя редактирование любой строки, содержащей имя, приведет к его соответствию настоящему определению.
Таким образом можно определить, что VB.NET в основном нечувствителен к регистру, но делает регистр идентификаторов доступным для среды CLR, которая может использовать эту информацию с учетом регистра.
источник
Я могу только предложить это, что, как я помню из моих учебников по программированию еще в начале 80-х, состоит в том, что чувствительные к регистру языки были (в то время) строго предназначены для уменьшения ошибок времени компиляции. Другими словами, «строгость» была предназначена для развития дисциплины кодирования с большей точностью. Как оказалось, добавление правильной маркировки переменных, классов, методов, функций и всего, что вы хотите добавить туда, также претерпело изменения.
Я помню, что почти все эти книги включали рекомендуемый образец использования заглавных букв, нижнего регистра и т. Д. Как мы все знаем, большая часть этого была выброшена или, я бы сказал, проигнорирована на практике, за исключением высокопроизводительных производств, и CASE решения, или для тех, кто достиг более высокого уровня квалификации. Я думаю, что каждый сталкивается с этой кривой обучения.
Учитывая развитие этих языков и IDE, возникает лучший вопрос: какой язык улучшает мое время разработки? Конечно, если вы не знакомы с каждым из различных языков, ваши возможности ограничены.
источник
Постараюсь ответить на ваш второй вопрос.
«Достаточно ли это убедительно для меня, чтобы подумать о переходе на C #, если ситуация с VB.NET каким-то образом ограничивает то, что я могу делать с кодом?»
Создайте WCF WebService с помощью C #. Создайте DataContract (1 класс). Один со свойством "строковый адрес электронной почты". Другой с "строковым адресом электронной почты" в качестве другого свойства. Ваш выбор - личный или служебный. Или это может быть два разных DataContracts.
Для C # это нормально. Веб-сервис создан нормально. Программа на AC # может легко создать WSDL, и все в порядке.
Теперь попробуйте создать WSDL с VB (любой версии). Он скажет, что «электронная почта» уже объявлена, и генерация WSDL не удалась.
Как и все, я предполагал, что это недостаток языка VB. Но!!!
Используйте FxCOP и проанализируйте исходный код C #. FxCOP говорит, что использование электронной почты / электронной почты является проблемой. Рекомендует использовать разные имена, поддерживающие нечувствительность к регистру. Также обратите внимание, что на сегодняшний день .NET framework имеет 106 языков программирования, и во многих языках включена чувствительность к регистру. Мы все движемся в сторону облака и хотим, чтобы наши услуги были доступны для всех платформ / языков программирования.
Так что чувствительность к регистру - это ваш выбор в вашей программе, и если вы парень C, вам это понравится. Если программа будет использоваться / доступна для других программ, отличных от C, вам необходимо поддерживать нечувствительность к регистру, но ваш язык - ваш выбор.
http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Visual_Basic_.NET http://www.vbrad.com/article.aspx?id=65
источник
Скрытие символов (например, поле local hides) также нечувствительно к регистру.
Вот пример :
Вывод компилятора VB.NET декомпилирован (и, следовательно, эквивалентен) следующему C #:
string.Equals
проходит поле дважды. Местное скрыто, независимо от случая. Язык нечувствителен к регистру.Чтобы явно сослаться на член, например на это поле, необходимо разыменовать член с помощью
Me
:источник
Я не видел, чтобы кто-нибудь прокомментировал ваш явный второй вопрос в конце: «2: достаточно ли это убедительно для меня, чтобы подумать о переходе на C #, если случай VB.NET каким-то образом ограничивает то, что я могу делать с кодом?»
Я предпочитаю более опционный подход, когда C # позволяет программисту выбирать, ограничивать ли возможности программиста. Я очень предпочитаю C #, но только из-за чувствительности к регистру я бы даже не подумал, что это близко к изучению языка только потому, что он чувствителен к регистру. важны все функции, и когда я смотрю на преимущества как C #, так и VB.NET, я очень предпочитаю C #. но я дам вам действительно сбалансированный взгляд, предвзятый да, потому что у меня есть предпочтения, но я также буду честен в отношении недостатков C #.
Во-первых, у обоих языков есть свои преимущества и недостатки. различия, которые вы можете сделать на одном языке, чего нельзя сделать на другом, сокращаются, поскольку, к счастью, Microsoft улучшает оба языка, и они, похоже, не проявляют несправедливого пристрастия к любому языку.
когда впервые появился C #, у VB не было комментариев XML, которые можно было бы помещать перед методами, которые мне нравились в C #. я ненавидел это в VB.NET. но за эти годы я видел, что многие функции, которых нет на одном языке, добавляются к другому. (одна и та же команда разработчиков MS разрабатывает и C #, и VB, поэтому логично, что функции должны стать очень похожими.)
но вы спросили, что есть в C #, а в VB нет. вот некоторые, о которых я могу сразу подумать:
1: C # более лаконичен и требует меньше ввода ... МНОГИМИ способами! я даже видел, как глупцы говорят, когда делается противоположное утверждение, что VB экономит печать. но послушайте, пожалуйста, людей, которые говорят вам, что они используют оба языка, и ни один из них не используется редко. я использую как C # иVB, C # дома, потому что мне это нравится (и когда я работаю с C # на работе), и мои последние запросы о работе, в которых я использую VB, а не C #. так что я все чаще использую VB (уже около 10 месяцев), но, по моим личным показаниям, я предпочитаю C #, а с точки зрения фактического набора текста VB значительно больше печатает. один пример, который я прочитал, где кто-то на самом деле пытался сказать, что VB был более кратким, давал пример 'with ...' с длинной переменной в with, поэтому в VB вы могли просто использовать '.property'. глупо утверждать, что VB нужно меньше печатать. есть несколько вещей (и не только в этом примере), где VB короче, но гораздо больше случаев, когда C # более краток на практике.
но самая большая причина, по которой я считаю C # более лаконичным, - это подробные инструкции VB «IF / THEN». если утверждения являются общими. в C # нет слова «тогда» для ввода! :) также все операторы 'end ...' требуют ввода, который в C # обычно представляет собой всего лишь одну закрывающую скобку '}'. Я читал, что некоторые люди утверждают, что эта более многословность в VB.NET является преимуществом для VB, поскольку несколько операторов / символов закрывающего блока могут быть вложены и заканчиваться сразу рядом друг с другом, но я совершенно не согласен. человек почти всегда может написать программу на C # или VB лучше, чем другой программист, потому что следующая версия кода может быть разработана лучше. это относится к «запутанным многочисленным закрывающим фигурным скобкам в C #» плюс, если все вложенные блоки имеют тот же тип, что и несколько вложенных IF, тогда VB страдает той же проблемой, что и в C #. в VB это не преимущество. именно эта ситуация является причиной того, что я люблю комментировать то, что соответствует моему закрывающему символу или закрывающему заявлению на обоих языках. да, это более многословно, но на любом языке у вас есть возможность пояснить, что важно в конкретных ситуационных делах, основанных на суждениях. Я считаю, что ясность кода очень важна.
2: VB не имеет многострочных комментариев. когда я работал с VB, я не возражал. затем я перешел на несколько языков в стиле C. Теперь я снова использую VB.NET на работе и скучаю по ним. это просто то, что вам удобно, а потом придется потерять. :(
3: «andalso» и «orelse» в VB довольно неприятно набирать все это, когда в C # это просто «&&» и «||». опять же меньше набора текста. это не редкость в моем коде как на VB, так и на C #. во всяком случае, для функциональности 'OR' против 'OrElse' обычно не имеет значения, за исключением того, что 'OrElse' быстрее для компьютера, поэтому, если программист просто использует 'Or' и 'And' в VB, он создает менее оптимальный код для тот, кому нравится ясность кода. «Или» гораздо легче пролистать, чем «OrElse».
4: больше гибкости в размещении кода на C #. когда строка длинная, и вы хотите перенести ее на следующую строку, я ненавижу "контролирующую" корректировку моего кода в VB.NET. C # делает это немного, но я считаю его более полезным в C #, тогда как в VB это гораздо больше контроля. но это скорее VB.NET IDE и C # IDE, чем сам язык. но я не знаю, нужны ли вам оба или чисто языковые функции без различий в IDE.
5: мне очень не хватает всего лишь создания нового блока кода на C #, у меня может много чего происходить в методе, и я хочу объявить переменную в очень маленьком блоке кода, но не объявить эту переменную вне этого блока в весь метод. в C # мы можем просто создать новый блок с помощью '{' и закончить его с помощью '}'. VB не имеет такой функции, но наиболее близким совпадением является безусловный блок «If True Then» и «End If». (обратите внимание на 2-символьный C # против 18-символьного эквивалента VB.NET снова ... больше ввода в VB.)
6: операторы самостоятельного увеличения и уменьшения: ++ и - как в
myVariable++
или++myVariable
или эквивалентных версиях декремента. это очень удобно ... иногда. вот пример реального кода, когда я сильно скучал по C #:И просто чтобы дать ОЧЕНЬ хороший пример правил C #, это еще один код, который я написал недавно:
Возможно, это достаточное доказательство того, что C # более лаконичен. Но не всем программистам нравится лаконичность. Некоторые предпочитают читать «если a <b, то ...», потому что это более естественно для их человеческого языка. И это нормально. Предпочтения в порядке. Для меня усилие руки - это значение фактора i, и я думаю, что любой может привыкнуть думать любыми символами, которые ему нравятся, поскольку «if» и «then» - это символы алфавита, а C # - «оператор if (условие);» синтаксис тоже символы. один просто ближе к синтаксису непрограммиста, чем другой. Я предпочитаю лаконичный.
Я также думаю, что необходимость использовать 'c' после символьных литералов в VB, чтобы сделать его символьным литералом, а не строкой, раздражает. Мне гораздо больше нравится лаконичность C #. когда для метода требуется символьный литерал, вам необходимо предоставить символ, а не строку с длиной в один символ, поэтому иногда вы вынуждены использовать
":"c
в VB, а в C # это':'
. Я думаю, что это придирки.Чтобы быть справедливыми, я скажу есть преимущества мне нравится VB , как не имеющие ставить пустые круглые скобки после вызова методов, как ,
Dim nameUpper$ = name.ToUpperInvariant
где C # требуют пустых скобок:string nameUpper = name.ToUpperInvariant()
. или вдвое больше , как обрезка тоже:Dim nameUpper$ = name.Trim.ToUpperInvariant
противstring nameUpper = name.Trim().ToUpperInvariant()
. Мне нравится краткое использование VB того, что я использовал$
выше, чтобы затемнить его «As String», где C # не имеет этих ярлыков. VB имеет эти ярлыки для типов String, Integer, Long, Decimal, Single и Double, но недостатком является то, что они менее понятны, поэтому я использую их с осторожностью. но тем не менее я предпочитаю лаконичный код.Что ж, это всего лишь несколько слов от этого опытного программиста, и, как я считаю, это мое «свидетельство» программирования C # и VB. Оба, на мой взгляд, хорошие языки. но да, я по-прежнему предпочитаю C #.
ps Так как я планирую программировать большую часть своей жизни, я даже заново научился печатать, используя наиболее эффективную клавиатуру: клавиатуру Дворжака, которая требует примерно 1/3 усилий для набора английского языка, чем на клавиатуре Qwerty. поищи это. возможно, вы тоже захотите переключиться. ;) мне стало легче печатать на 67%! :) Я призываю всех мыслить нестандартно и оценивать эффективность своей работы. Упрощенная раскладка клавиатуры Дворжака и C # сделали это за меня. :)
PSS Я бы сравнил Dvorak и C # с метрикой, в отличие от раскладки клавиатуры Qwerty, и VB с эмпирическими измерениями. Дворжак, метрика и C # просто «чистые». НО VB не сильно отстает. Но он страдает от необходимости быть обратно совместимым со старым кодом VB6 и кодом до .NET, например, «Or» против «OrElse» и «IIF ()».
Я заканчиваю с осторожностью. Пожалуйста, будьте более осмотрительны, чем прислушивайтесь к людям, которые на самом деле не понимают, о чем они говорят. Половина всех минусов как VB, так и C # - небольше нет проблем, и люди все еще пишут о том, что они не знают, какие недостатки действительно все еще существуют в языке. Лучший пример, который я могу придумать, - это XML-комментарии для методов, использующих тройной апостроф в VB или символы комментария с тройной косой чертой в C #. Но, пожалуйста, определите для себя, говорит ли человек по незнанию или по опыту. Личное свидетельство означает, что они знают на собственном опыте. А после того, как у кого-то будет большой опыт в этом, тогда придайте уши. У меня более 10 лет опыта как в C #, так и в VB. И все сводится к следующему: оба (очень) хорошие языки. И большинство различий вы можете увидеть сразу через 5 минут после чтения кода. Но да, на поиск других функций могут уйти годы. И один недостаток, о котором я знаю (в C #), я могу ' Я даже не думаю о реальной жизненной ситуации, когда это было бы полезно. Так что, возможно, это все-таки не помеха.
Удачного кодирования!
источник
VB.NET нечувствителен к регистру.
Примеры:
1.
2.
3.
Весь этот код выдаст ОШИБКУ ВРЕМЕНИ КОМПИЛЯЦИИ .
В первом примере будет показана ошибка: «Локальная переменная« A »уже объявлена в текущем блоке».
В то время как для 2-го и 3-го примеров будет отображаться сообщение об ошибке «Public Sub b ()» имеет несколько определений с идентичными подписями ». и «'Public Function c () As Integer' имеет несколько определений с идентичными подписями.» соответственно.
Из этих ошибок обратите внимание, что ошибки возникают в разных позициях для переменных и процедур / функций. Для переменных ошибка выдается при втором объявлении, а для процедур / функций - при первом объявлении / определении идентичного кода.
Как сказал пользователь в комментарии где-то выше, код VB.NET постоянно проверяется и / или корректируется в фоновом режиме; вы можете увидеть эту ошибку в окне «Список ошибок» в VS IDE. И поскольку это ОШИБКА, а НЕ ПРЕДУПРЕЖДЕНИЕ , код не будет компилироваться, пока ошибка не будет устранена.
источник