Чи справді VB нечутливий?


122

Я не намагаюся тут заводити аргументи, але з будь-якої причини, як правило, сказано, що Visual Basic є нечутливим до регістру, а мови C - ні (і це якось добре).

Але ось моє запитання: Де саме нечутливий регістр Visual Basic? Коли я набираю ...

Dim ss As String
Dim SS As String

... у IDE Visual Studio 2008 або Visual Studio 2010 , другий має попередження про " Місцева змінна SSвже оголошена в поточному блоці ". У VBA VBA він не відразу видає помилку, а просто автоматично виправляє випадок.

Я щось тут пропускаю з цим аргументом, що Visual Basic не відрізняється від регістру? (Крім того, якщо ви знаєте або хочете відповісти, чому це було б погано?)

Чому я навіть задаю це питання?

Я вже багато років використовую Visual Basic у багатьох своїх діалектах, іноді як любитель, іноді для програм, пов’язаних з малим бізнесом у робочій групі. За останні півроку я працював над великим проектом, набагато більшим, ніж я передбачав. Значна частина зразкового вихідного коду є в C #. У мене немає горячого бажання вивчати C #, але якщо є якісь речі, яких я пропускаю в тих пропозиціях C #, яких Visual Basic не має (навпаки, VB.NET пропонує XML Literals ), тоді я хотів би щоб дізнатися більше про цю особливість. Тож у цьому випадку часто доводиться, що мови C залежать від регістру, і це добре, а Visual Basic є нечутливим до регістру, а це погано. Я хотів би знати ...

  1. Наскільки саме візуальний регістр Visual Basic нечутливий, оскільки кожен приклад у редакторі коду стає чутливим до регістру (тобто випадок виправляється), хочу я цього чи ні.
  2. Чи достатньо мені цього переконливого, щоб розглянути можливість переходу до C #, якщо випадок VB.NET якимось чином обмежує те, що я міг би зробити з кодом?

5
+1 Я раніше замислювався над саме цим самим.
NakedBrunch

7
Еммм ... не впевнений , що ви розумієте , що прецедентний в чутливих засобах. Оскільки VB насправді нечутливий, SS та s - це одне й те саме ім'я, тоді як у C вони не були б.
Ред С.

1
@ed: Я не можу використовувати і те, SSі ssв VB, залежно від того, що я використовую спочатку - той, який використовує редактор.
Todd Main

1
Отаку, я, безумовно, рекомендую зосередити це питання на тому, що саме означає, що VB нечутливий до регістру та як він реалізується. Питання про те, чи краще для мови бути нечутливою до регістру, може, на жаль, почати полум'яну війну. Якщо вам справді цікаво, поставте це в іншому запитанні. (Раджу не робити, але якщо ви повинні потім позначити це суб'єктивно і зробити його вікі спільнотою)
MarkJ

16
Ви (або думали) про це думкою догори. Саме тому, що компілятор не чутливий до регістру, помилка читає "змінну SS вже оголошено". Якщо це враховує регістр, ви отримаєте або змінну ss not used ', або зовсім не помилку, і помилку, якщо ви використовували альтернативну то і іншу.
Адріано Варолі П'яцца

Відповіді:


108

Різниця між VBA та VB.NET полягає лише в тому, що VB.NET постійно збирається у фоновому режимі. Під час складання VBA ви отримаєте помилку.

Як каже Джонатан , при програмуванні ви можете вважати VB.NET нечутливим до регістру, окрім порівняння рядків, XML та кількох інших ситуацій ...

Я думаю, що тебе цікавить те, що знаходиться під кришкою. Ну,. Runtime .NET Common Language відрізняється від регістру , і код VB.NET покладається на час виконання, тому ви можете бачити, що він повинен залежати від регістру під час виконання, наприклад, коли він шукає змінні та методи.

Компілятор і редактор VB.NET дозволяє вам ігнорувати це - оскільки вони виправляють випадок у вашому коді.

Якщо ви граєте з динамічними функціями або пізньою прив'язкою (Option Strict Off), ви можете довести, що базовий час виконання залежить від регістру. Ще один спосіб зрозуміти, що це зрозуміти, що чутливі до регістру мови, такі як C #, використовують один і той же час виконання, тому час виконання, очевидно, підтримує чутливість до регістру.

EDIT Якщо ви хочете вийняти IDE з рівняння, його завжди можна скласти з командного рядка . Змініть код в Блокноті , так що є ssі SSпобачити , що робить компілятор.

Цитата редагування від Джеффрі Ріхтера в .NET Framework Design Guidelines page 45.

Щоб було зрозуміло, CLR насправді залежить від регістру. Деякі мови програмування, наприклад Visual Basic, нечутливі до регістру. Коли компілятор Visual Basic намагається вирішити виклик методу типу, визначеному на чутливій до регістру мові, як C #, компілятор (а не CLR) визначає фактичний регістр імені методу та вбудовує його у метадані. CLR про це нічого не знає. Тепер, якщо ви використовуєте відображення для прив'язки до методу, API-інтерфейси відображення пропонують можливість робити нечутливі до регістру пошуки. Це те, наскільки CLR пропонує нечутливість до випадку.


Найкраща відповідь, яку я чув досі. Чи є якийсь спосіб довести це, що компілятор і редактор VB.Net дозволив вам ігнорувати це ? Чи є спосіб дещо відключити автоматичне виправлення? Або є спосіб скласти sln, який не записаний у VS IDE в MSBuild, який використовує ssі те, SSі він буде компілювати та працювати так, як очікувалося?
Тодд Майн

5
Ви можете вимкнути автоматичне виправлення шляхом обману. Клацніть правою кнопкою миші файл vb і виберіть "Відкрити за допомогою". Потім виберіть щось на кшталт "XML (Text) Editor". Ви втратите всю функціональність для VB, як-от автоматичне виправлення.
Джонатан Аллен

+1 чудова відповідь, і хороший запитання, а також Отаку (я думаю, ви вже знали, але хотіли зробити чітке визначення так?)
Анонімний Тип

Компілятор / IDE VB.NET не є 100% нечутливим до регістру. Наприклад Dim pdfWriter As PDFWriter, цілком діє. VB.NET дозволяє розмежовувати назви класів та назви змінних, що є приємним штрихом, оскільки це звичайна практика у повністю залежних від регістру мовах.
інгредієнт_15939

Шлях VB підходить для взаємодії. Приклад: Створіть DLL в C # з електронною поштою як String та Email () як властивість, в якій подія inotifypropertychanged. C # складе добре, і DLL буде сформовано. Спробуйте посилатися на цю DLL у VB або будь-якій подібній мові. Це скаже, що в бібліотеці є конфлікт між змінною електронною поштою / електронною поштою. Засоби аналізу коду вказують на це як у компіляторі C #, а не у компіляторі VB.
Венкат

22

Частина проблеми полягає в тому, що вам потрібно розділити мову від досвіду IDE.

Щодо мови, VB.NET , безумовно, нечутливий до ідентифікаторів. Дзвінок DateTime.Parseіdatetime.parse зв’яжеться з точно таким же кодом. І на відміну від таких мов, як C #, неможливо визначити способи чи типи, які відрізняються лише у кожному випадку.

Як IDE, VB.NET намагається зберегти випадок існуючих ідентифікаторів, коли він досить перераховує блок коду. Приблизні списки трапляються щоразу, коли ви переходите від поточного логічного рядка коду. У цьому випадку ви переходите до другої декларації SS, досить симпатичний лістер помічає, що існує ідентифікатор з цим іменем, і виправляє його, щоб він мав відповідність.

Ця поведінка, однак, суто робиться як додаток до вартості користувача. Це не частина основної мови.


1
Дякую Джареду, цікаво знати, що це лише ІДЕ. Я все ще не розумію, чому було б добре, щоб більше ніж одне ім’я представляло різні речі за різницею випадків у назві, але я думаю, що це вже інший день.
Тодд Майн

1
Я не думаю, що Джаред мав на увазі, що це лише ІДЕ. Я думаю , що він сказав , що компілятор НЕ чутливий до регістру, тому він вважає , що ssідентично SS, але і в якості допоміжного засобу для читання IDE виправляють , SSщоб ssпри введенні тексту. Тож навіть якщо IDE не виправив цей випадок, компілятор все одно побачив би два ідентифікатори як однакові.
MarkJ

2
"Я все ще не розумію, чому було б добре, щоб більше ніж одне ім'я представляло різні речі за різницею відмінків у назві" <- я відчував те саме перед переходом з VBA / VB6 / VB.NET на C # , Я вважав, що наявність імен відрізняється лише від випадків, здавалося, абсолютно небезпечно. На практиці, однак, це виявляється досить корисним і, на диво, зовсім не схильним до помилок.
Майк Розенблум

2
@Mike Я дуже не згоден з цим пунктом. Я ніколи не бачив змішаних імен, які б нічого не робили, але викликали плутанину.
JaredPar

2
Дійсно? Я маю на увазі щось на зразок недійсного SetColor (кольоровий колір) {this.color = color}; Я усвідомлюю, що це може виглядати небезпечно, але воно працює безперебійно, компілятор не дозволить вам помилитися, а IntelliSense надає вам правильних членів після "кольору". vs. "Колір." Мене тут хвилює те, що використання "цього" не потрібно - це застосовується FxCop та / або StyleCop (я забуваю, який), але я хотів би, щоб було налаштування, щоб IDE завжди застосовував це під час доступу до класу члени, а не потенційно дозволяють випадково затінити область.
Майк Розенблум

16

VB в основному нечутливий до випадків, але є винятки. Наприклад, XML-літерали та розуміння залежать від регістру. Порівняння рядків зазвичай чутливе до регістру, на відміну від T-SQL, але є компілятор, що робить порівняння рядків рядків нечутливими. І звичайно, є певні випадки, коли йдеться про спадкування, COM та динамічну мову виконання.


3
Гарні моменти щодо того, в якому випадку справа має значення, як XML Literals та порівняння рядків. Але коли ми говоримо, що це здебільшого нечутливі до випадків, про що ми саме говоримо? Перейшовши до Outlook VBA, як приклад, якщо я введу Dim mi as mailitemі subject = mi.subject, імена об'єктів будуть автоматично виправлені до MailItemта mi.Subject. Невже компілятор дбає (тому що це завжди буде автоматично виправлено) чи це гарний код чи ...?
Тодд Майн

1
Компілятор не хвилює. Ви можете перевірити це, відредагувавши файл у блокноті та скориставшись компілятором командного рядка.
Джонатан Аллен

9

Так, компілятор VB.NET обробляє ідентифікатори нечутливим до випадку. І так, це може спричинити проблеми, коли він споживає збірки, написані іншою мовою або використовує компоненти COM. Перший випадок охоплюється Загальною мовною специфікацією . Відповідне правило:

Для того, щоб два ідентифікатори вважалися різними, вони повинні відрізнятись більше, ніж лише їхній випадок.

Справа COM досить жорстоко опікується будівельником бібліотек типів, він змушує ідентичні корпуси ідентифікаторів з тим самим іменем. Навіть коли ці ідентифікатори виконують різні ролі. Іншими словами, параметр методу з назвою "індекс" змусить назву методу "Індекс" перейти в "індекс". Це призвело до численних подряпин по голові, як ви могли собі уявити :)


6

VB зберігає випадок (у IDE), але нечутливий до регістру . Це схоже на файлову систему Windows. Hello.txt і hello.txt вважаються одним і тим же ім'ям файлу.

IDE передбачає, що змінною декларації є "правильний" випадок для цієї змінної, і коригує кожен екземпляр цієї змінної, що відповідає заяві. Це робиться з окулярів і консистенції очей, але не для функціональності.

Я бачив кілька випадків, коли випадок не змінювався автоматично, щоб він відповідав декларації, а заява працює точно так само. Ви також можете скористатися будь-яким текстовим редактором, щоб написати код, який складатиметься чудово у різних випадках.

Побічна примітка:

Більшість людей вважають невідчутним до випадків. Коли ми бачимо слово "собака", це слово перекладається на значення в нашій свідомості. Сенс слова не грунтується на разі (тобто незалежно від того, якщо цього заклинання «DOG», «собачка», або «собачка» все ще гавкає.) COMPUTERS см слова як дискретні пакети біт. Великі і малі регістри є різними моделями бітів, і тому вони різні.

Оскільки більшість програмістів є людьми, нечутливість до випадків здається більш пристосованою до того, як люди думають, а чутливість до справи більше стосується того, щоб люди адаптували свій погляд до обмежень машини.


4
За винятком того, що програмістам потрібно розрізняти об'єкти та класи, і вони традиційно використовували зміну у випадку, якщо це зробити (не потрібно, лише умова). Так що object.method()і Object.Method()миттєво розпізнаються як посилання та методи об’єктів і класів (якщо ви відповідаєте цьому умовам кодування). Як і в англійській мові, ви виділяєте власні іменники та початки речень з великої літери. Тож під час читання чи програмування я не думаю, що справа буває нечутливою, інакше мені не вистачить сенсу.
Jason S

@Jason, це все про те, до чого ти звик. Студенти, які програмують на С, спочатку пропонують безліч скарг на чутливість справи, потім, після кількох курсів, звикають до цього. Object.method () та Object.Method () - це лише умова, і це найсильніший випадок щодо чутливості до регістру. Мені довелося змінити програму, написану кимось іншим, яка мала дві змінні з назвою temp і Temp в однаковій області, і я скажу вам, що було дуже важко тримати їх прямо в моїй голові. І хоча ми можемо розпізнати загальний іменник за великої літери, слова "bob" і "Bob" означають те саме в нашому мозку.
Ендрю Нілі

Чому IDE зберігає випадок у такому випадку? (вибачте) Я думаю, що IDE зберігає випадок, тому що дизайнери MS вважають, що у мозку справа має семантичний характер. Але в дійсності VB IDE вважає formі Formте ж саме, що мені все одно, заплутаним. У разі (вибачте ще раз), з tempі Tempви можете легко використовувати інструменти рефакторинга в C # перейменувати Tempв bobTempабо будь-який інший . Однак я підтримую деякий VB, і хтось пішов і зробив Dim form As Form. Тепер, коли я перейменую, він перейменовує як посилання класу, так і об'єкта. Блея!
Jason S

@Jason, у VB я завжди кажу "Dim aform as Form", але я відволікаюсь. VB підтримує чутливість регістру в пошуку. Також я шукав би "As Form" і замінив його на "somethingstupid", потім перейменував би форму на щось розумне, потім перейменував би "somethingstupid" назад у "As Form". Насправді мені подобається, що це змінює регістр, тому що він підтверджує, що я не жив пальцем ім'я змінної.
Ендрю Нілі

Так, але це не є заміною інструменту рефакторингу, який розрізнятиме посилання класу та екземпляра, коли імена однакові (або відрізняються лише у випадку VB). Здається, що інструменти рефакторингу C # можуть це зробити. Я не називаю класи та інстанції однаково. У C # я буду використовувати регістр для розрізнення, але в VB я не можу цього зробити, тому я використовую букви для передбачення. Очевидно, моя проблема полягає в тому, що я підтримую код когось elses, який використовував те саме ім'я. Але ця дискусія стає занадто великою для коментарів, тому я залишу її тут.
Jason S

5

Це частина редактора, який ви використовуєте, вони можуть вести себе по-різному, але факт полягає в тому, що Visual Basic дійсно є нечутливою до регістру мовою. Отже, ssі SSтакі самі.

Будь ласка, перегляньте підручник з основ VB.NET для отримання додаткової інформації :)


о, це цікаво. є якесь місце я дивлюся цю деталь? я ще не пройшов тестування, але, думаючи про VBScript, ти можеш мати рацію.
Todd Main

@Otaku: будь ласка, дивіться мою відповідь ще раз, я надав посилання зараз. Спасибі
Сарфраз

Я досить знайомий з VB, дякую :) Я не впевнений, що ви хочете, щоб я дивився на цій сторінці.
Тодд Майн

3

Я не впевнений, що тебе розумію? VB нечутливий до регістру, тому ss і SS - одна і та ж змінна, тому компілятор правильно скаржиться, що ви повторно оголосили змінну.

Я думаю, що змінні не відрізняються від регістру, але назви функцій є.


але якщо я використовую, ssа потім набираю пізніше SS, він автоматично виправляється ss, що призводить до того, що я вважаю, що компілятор дійсно піклується про випадок.
Тодд Майн

5
@oTAKU: Це IDE, що змінює регістр, а не компілятор.
Джон Сондерс

2
VB досі не дуже переймається справою. IDE намагається очистити код, щоб змінні залишалися однаковими протягом усього часу.
гітарист

1

Так, VB нечутливий до регістру. Він іноді кидає тих, хто до цього не звик, за шлейф.


1

Не потрібно намагатись у VB.NET створити код з різними "написаннями" великого / малого ідентифікатора. Зміна корпусу ідентифікатора у файлі, де він оголошений без використання функції «Перейменувати», не призведе до оновлення імені в інших файлах, хоча редагування будь-якої рядки, що містить ім’я, призведе до відповідності цьому визначенню.

Таким чином можна визначити, що VB.NET здебільшого нечутливий до регістру, але він робить випадок ідентифікаторів доступними для CLR, які можуть використовувати цю інформацію в залежності від регістру.


1

Я можу запропонувати лише це, що, як я пам’ятаю з моїх підручників з програмування ще на початку 80-х років, - це те, що чутливі мови випадків були (на той час) суворо призначені для зменшення помилок під час збирання. Тобто «суворість» мала на меті розвивати дисципліну кодування більшої точності. Як виявилося, додавання належного маркування змінних, класів, методів, функцій і всього іншого, що ви хочете туди вписати, також розвинулося.

Я пригадую, що майже всі ці книги включали рекомендований зразок для капіталізації, малого регістру тощо. Як ми всі знаємо, багато з цього було викинуто або, як я можу сказати, ігноруватися на практиці, окрім виробничих будинків високого класу та CASE рішення або для тих, хто досяг більш високого рівня кваліфікації. Я думаю, що кожен відчуває цю криву навчання.

З огляду на просування цих мов та IDE, то краще питання, яка мова покращує час мого розробника? Звичайно, якщо ви не знайомі з кожним із різних мов, ваші варіанти обмежені.


1

Я спробую відповісти на ваше друге запитання.

"Чи достатньо мені цього переконливого, щоб розглянути можливість переходу до C #, якщо випадок VB.NET якимось чином обмежує те, що я міг би зробити з кодом?"

Створіть WCF WebService за допомогою C #. Створіть DataContract (1 клас). Один із властивістю "string email". Інший із "string email" як ще одна властивість. Ваш вибір потрібно розуміти як особисту електронну пошту чи службову пошту. Або це може бути в двох різних DataContracts.

Для C # це добре. Веб-сервіс створений чудово. Програма AC # може легко створити WSDL і все в порядку.

Тепер спробуйте створити WSDL з VB (будь-яка версія). Він скаже, що "електронна пошта" вже оголошена, а покоління WSDL не працює.

Як і всі, я припускав, що це недолік мови VB. Але !!!

Використовуйте FxCOP і аналізуйте оригінальний код C #. FxCOP каже, що використання електронної пошти / електронної пошти є проблемою. Рекомендує використовувати іншу назву, що підтримує нечутливість регістру. Також зауважте, що на сьогоднішній день .NET Framework має 106 мов програмування, і є багато мов, що мають чутливість до регістру. Всі ми рухаємося до хмари та хочемо, щоб наші послуги були доступними для всіх платформ / мов програмування.

Тож, залежність від обліку у регістрі - це ваш вибір у вашій програмі, і якщо ви хлопець C, ви б хотіли цього. Якщо програма буде використовуватися / отримувати доступ до інших програм, що не стосуються С, вам потрібно підтримати нечутливість до випадків, але ваша мова - це ваш вибір.

http://en.wikipedia.org/wiki/Comppare_of_C_Sharp_and_Visual_Basic_.NET http://www.vbrad.com/article.aspx?id=65


Хмара використовує URI, залежні від регістру (що особливо важливо для проксі-серверів та кеш-серверів).
бінкі

1

Приховування символів (наприклад, місцеве приховане поле) також нечутливо.

Ось приклад :

Public Class C
    Public Name As String

    Public Function M(name As String) As Boolean
        Return String.Equals(name, Name) ' case differs
    End Function
End Class

Вихід компілятора VB.NET декомпілюється до (і тому еквівалентний) наступному C #:

public class C
{
    public string Name;

    public bool M(string name)
    {
        return string.Equals(name, name); // both lowercase
    }
}

string.Equalsпередається поле двічі. Місцевий прихований, незалежно від випадку. Мова є нечутливою до регістру.

Щоб явно посилатись на члена, наприклад, на це поле, вам слід знецінити його за допомогою Me:

Return String.Equals(name, Me.Name) ' differentiate field from local

0

Я не бачив, щоб хтось коментував ваше явне 2-е запитання в кінці: "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 був більш стислим, наводив приклад "з ..." з довгою змінною в с, тому в VB ви можете просто використовувати ".property". це дурість стверджувати, що VB потрібно менше друкувати. Є кілька речей (і не лише цей приклад), де VB коротший, але набагато більше разів, коли C # більш стислий, в реальній практиці.

але найбільша причина, на яку я вважаю, C # є більш стислою, - це багатослівний вислів VB "ЯК / ТО". якщо твердження є загальними. в C # немає слово "тоді" набрати! :) також усі "закінчення ..." заяви набирають текст, який у c #, як правило, є лише одним заключним дужкою "}". Я читав, що деякі люди стверджують, що це більше багатослівність у VB.NET є перевагою для VB, оскільки декілька висловлювань / символів закритого блоку можуть вкладатись і закінчуватися безпосередньо поруч, але я зовсім не згоден. людина майже завжди може написати програму краще в C # або VB, ніж інший програміст, оскільки наступна редакція коду могла бути розроблена краще. це стосується "заплутаного численних дужок закриття в C #" плюс, якщо вкладені блоки є одного типу, як кілька вкладених IF, тоді VB страждає від тієї ж проблеми, що і в C #. це не є перевагою у VB. саме ця ситуація саме тому мені подобається коментувати те, що стосується мого символу завершення чи заключного виступу на обох мовах. так, це потрібно більш багатослівно, але в будь-якій мові у вас є можливість бути чітким, що важливо в судженнях, конкретних ситуаційних ситуаціях. Я думаю, що чіткість коду є досить важливою.

2: VB не має багаторядкових коментарів. коли я працював з VB, я не проти. тоді я перейшов до декількох мов стилю С. зараз я повертаюсь здебільшого за допомогою VB.NET на роботі, і я їх сумую. це просто те, що вам здається зручним, а потім доведеться втратити. :(

3: "andalso" та "orelse" VB - це досить прикро набирати все, що в C # це просто "&&" та "||". знову ж таки, менше набирайте текст. це не рідкість у моєму коді як у VB, так і в C #. якщо що-небудь, для функціональності 'OR' vs '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 True" та "End If". (зверніть увагу на 2-символьний C # проти 18 символів VB.NET еквівалент знову ... більше введення в VB.)

6: оператори самостійного збільшення та зменшення: ++ та - як у myVariable++або ++myVariableеквівалентних версіях зменшення. це дуже зручно ... іноді. ось приклад фактичного коду, коли я сильно пропустив C #:

// C#:
while (txt.Length > x)
{
    thisChar = txt[x];
    if (charsAllowedWithoutLimit.Contains(thisChar)) { ++x; }
    else if (allowLettersWithoutLimit && char.IsLetter(thisChar)) { ++x; }
    else if ((x2 = charsAllowedWithLimit.IndexOf(thisChar)) >= 0)
    {
        ++x; if (++usedCountA[x2] > charAllowedLimit[x2]) { break; }
    }
    else { break; }
}

' VB.NET:
While (txt.Length > x)
    thisChar = txt(x)
    If (charsAllowedWithoutLimit.Contains(thisChar)) Then
        x += 1
    ElseIf (allowLettersWithoutLimit AndAlso Char.IsLetter(thisChar)) Then
        x += 1
    Else
        x2 = charsAllowedWithLimit.IndexOf(thisChar)
        If (x2 >= 0) Then
            x += 1
            usedCountA(x2) += 1S
            If usedCountA(x2) > charAllowedLimit(x2) Then Exit While
        Else
            Exit While
        End If
    End If
End While

І просто навести ДУЖЕ хороший приклад, де правила C # - це більше код, який я особисто писав нещодавно:

// C#
public static bool IsNotWithin(this Byte   v, Byte   v1, Byte   v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this SByte  v, SByte  v1, SByte  v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this Int16  v, Int16  v1, Int16  v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this Int32  v, Int32  v1, Int32  v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this Int64  v, Int64  v1, Int64  v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this UInt16 v, UInt16 v1, UInt16 v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this UInt32 v, UInt32 v1, UInt32 v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this UInt64 v, UInt64 v1, UInt64 v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this Decimal v, Decimal v1, Decimal v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }

public static bool IsWithin(this Byte   v, Byte   v1, Byte   v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this SByte  v, SByte  v1, SByte  v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this Int16  v, Int16  v1, Int16  v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this Int32  v, Int32  v1, Int32  v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this Int64  v, Int64  v1, Int64  v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this UInt16 v, UInt16 v1, UInt16 v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this UInt32 v, UInt32 v1, UInt32 v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this UInt64 v, UInt64 v1, UInt64 v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this Decimal v, Decimal v1, Decimal v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }

' And the VB equivalent is a mess! Here goes:
<Extension()>
Public Function IsNotWithin(v As Byte, value1 As Byte, value2 As Byte) As Boolean
    Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function

<Extension()>
Public Function IsNotWithin(v As SByte, value1 As SByte, value2 As SByte) As Boolean
    Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function

<Extension()>
Public Function IsNotWithin(v As Int16, value1 As Int16, value2 As Int16) As Boolean
    Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function

' the % suffix means 'As Integer' in VB.
<Extension()>
Public Function IsNotWithin(v%, value1%, value2%) As Boolean
    Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function

' the & suffix means 'As Long' in VB.
<Extension()>
Public Function IsNotWithin(v&, value1&, value2&) As Boolean
    Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function

<Extension()>
Public Function IsNotWithin(v As UInt16, value1 As UInt16, value2 As UInt16) As Boolean
    Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function

<Extension()>
Public Function IsNotWithin(v As UInt32, value1 As UInt32, value2 As UInt32) As Boolean
    Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function

<Extension()>
Public Function IsNotWithin(v As UInt64, value1 As UInt64, value2 As UInt64) As Boolean
    Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function

' the @ suffix means 'As Decimal' in VB.
<Extension()>
Public Function IsNotWithin(v@, value1@, value2@) As Boolean
    Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function

<Extension()>
Public Function IsWithin(v As Byte, value1 As Byte, value2 As Byte) As Boolean
    Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function

<Extension()>
Public Function IsWithin(v As SByte, value1 As SByte, value2 As SByte) As Boolean
    Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function

<Extension()>
Public Function IsWithin(v As Int16, value1 As Int16, value2 As Int16) As Boolean
    Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function

' the % suffix means 'As Integer' in VB.
<Extension()>
Public Function IsWithin(v%, value1%, value2%) As Boolean
    Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function

' the & suffix means 'As Long' in VB.
<Extension()>
Public Function IsWithin(v&, value1&, value2&) As Boolean
    Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function

<Extension()>
Public Function IsWithin(v As UInt16, value1 As UInt16, value2 As UInt16) As Boolean
    Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function

<Extension()>
Public Function IsWithin(v As UInt32, value1 As UInt32, value2 As UInt32) As Boolean
    Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function

<Extension()>
Public Function IsWithin(v As UInt64, value1 As UInt64, value2 As UInt64) As Boolean
    Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function

' the @ suffix means 'As Decimal' in VB.
<Extension()>
Public Function IsWithin(v@, value1@, value2@) As Boolean
    Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function

Можливо, це свідчить про те, що C # є більш стислим. Але не всі програмісти люблять стислість. Деякі вважають за краще читати "якщо a <b тоді ...", оскільки це природніше для їх людської мови. І це просто чудово. Переваги прекрасні. Для мене зусилля рук - це значення фактора, і я думаю, що кожен може звикнути думати про будь-які символи, які їм подобаються, бо "якщо" і "тоді" - це символи алфавіту, а C # 's "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 # vs VB. обидва є гарними мовами, на мій погляд. але так, я все ще віддаю перевагу C #.

ps Оскільки я планую програмувати протягом більшої частини свого життя, я навіть навчився набирати текст, використовуючи найефективнішу клавіатуру: клавіатуру Dvorak, яка вимагає приблизно 1/3 зусиль для введення англійської мови, ніж на клавіатурі Qwerty. подивіться. можливо, ви також можете переключитися. ;) це полегшило моє введення на 67%! :) Я закликаю когось задуматися поза межами та оцінити кращу ефективність у вашій роботі. Спрощена розкладка клавіатури Dvorak і C # зробили це для мене. :)

PSS я би порівняв метрику Дворака і С # на метрику на відміну від розкладки клавіатури Qwerty, а VB - з вимірюванням Empirial. Дворак, метрика та C # просто "чисті". АЛЕ ВБ не дуже відстає. Але це страждає від необхідності бути зворотним сумісним зі старим кодом VB6 та попереднім кодом .NET, як-от "Або" проти "OrElse" та "IIF ()".

Закінчую обережно. Будь ласка, будьте більш обережні, щоб слухати людей, які насправді не знають, про що говорять. Половина всіх мінусів проти VB та C # не єбудь-яке питання більше, і люди все ще публікують про них, не знаючи про те, які недоліки дійсно все ще існують у мові. Найкращий приклад, про який я можу придумати, - це коментарі XML для методів, що використовують потрійний апостроф у VB або символи коментування потрійної косої риски в C #. Але, будь ласка, розпізнайте для себе, чи говорить людина через незнання чи досвід. Особисті свідчення означають, що вони знають з реального досвіду. А після того, як хтось має багато досвіду в цьому, тоді заграйте у вуха. Я маю понад 10-річний досвід роботи як в C #, так і в VB. І це зводиться до цього: обидва є (дуже) гарними мовами. І більшість відмінностей ви можете побачити відразу протягом 5 хвилин після читання коду. Але так, інші функції можуть зайняти роки, щоб знайти гандикап. І один гандикап, про який я знаю (в C #), я можу " t навіть не думати про реальну життєву ситуацію, де це було б корисно. Тож, мабуть, це не гандикап.

Щасливого кодування!


Я ціную всі деталі, але ваш приклад не використовує чутливість / нечутливість до регістру (наскільки я міг сказати), щоб показати, чому C # якось "краще".
Тодд Майн

Я спробував відповісти на друге питання прямим прикладом.
Венкат

@ToddMain, правильно. І мій приклад не використовує чутливість до регістру, щоб показати, чому C # кращий, оскільки питання не задає, чому чутливість регістру робить його кращим. Крім того, я вірю, що ця особливість говорить сама за себе. І я вважаю, що логіка є основним принципом, який більшість людей може зробити це самим. Але якщо хтось запитає, я радий допомогти їх крокувати через логіку. Але це, мій друг, на мою думку, це вже інше питання. ;)
Шон Ковач

Власне, це було одне з двох запитань у початковій публікації. Це не само собою зрозуміло, саме тому я запитав. Але не хвилюйтеся, якщо не вирішити це питання.
Todd Main

@ToddMain, я бачу вашу думку. дійсно дуже справедливий момент. :) Дякую, що розплющив очі на це. :)
Шон Ковач

0

VB.NET нечутливий до регістру.

Приклади:

1.

Dim a As Integer
Dim A as Integer

2.

Sub b()
    'Some statement(s) here
End Sub
Sub B()
    'Some statement(s) here
End Sub

3.

Function c() As Integer
    'Some statement(s) here
End Function
Function C() As Integer
    'Some statement(s) here
End Function

Ці всі коди будуть кидати ПОМИЛКУ СКЛАДНОГО ЧАСУ .

У першому прикладі буде показана помилка: "Локальна змінна" A "вже оголошена в поточному блоці."

У той час як для 2-го та 3-го прикладу буде показана помилка, що говорить: "Public Sub b ()" має кілька визначень з однаковими підписами. " та "'Публічна функція c () As Integer' має кілька визначень з однаковими підписами." відповідно.

З цих помилок зауважте, що помилки викидаються в різні позиції для змінних та процедур / функцій. Для змінних помилка кидається у 2-му оголошенні, тоді як для процедур / функцій - при першому оголошенні / визначенні ідентичного коду.

Як сказав користувач у коментарі десь вище, код VB.NET постійно перевіряється та / або виправляється у фоновому режимі; Ви можете побачити цю помилку у вікні "Список помилок" у VS IDE. Оскільки це ПОМИЛКА, а НЕ ПОПЕРЕДЖЕННЯ , код не збирається, поки помилка не буде усунена.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.