Как мы уже писали ранее*, в будущей версии Visual Basic.NET Visual Basic-программистов ожидает огромное число новшеств. Сюрпризов будет много и боюсь, что не все из них будут восприняты разработчиками с ликованием. Один из неприятных "подарков" заключается в том, что впервые за десятилетнюю историю Visual Basic нарушается совместимость программного кода "снизу вверх".

Microsoft обещает создать специальные средства для модификации кода приложений, созданных в предыдущих версиях, но даже если это случится, то почти наверняка далеко не все 100% ваших программ, написанных на Visual Basic 6.0, будут работать в Visual Basic.NET. Самое неприятное в этой ситуации - то, что некоторые старые конструкции будут правильными с точки зрения синтаксиса и транслятор не выдаст сообщения об ошибках, но в Visual Basic.NET этот код будет работать не так, как в Visual Basic 6.0.

Хотелось бы особо подчеркнуть, что речь идет в основном об изменениях в синтаксисе языка, а не в функциональности системы программирования. Рассмотрение новых функций и средств Visual Basic -- это тема отдельного разговора.

Важно отметить еще вот что. То, что известно сейчас, это результат знакомства с Visual Basic.NET Beta 1 и материалами Microsoft (т.е. это информация на начало 2001 года). Мне кажется, что корпорация в настоящее время внимательно изучает реакцию сообщества разработчиков на предлагаемые новшества и к моменту появления окончательной версии состав инноваций может измениться (правда, в обе стороны -- что-то исчезнет, а что-то добавится).

Надо сказать, что Visual Basic.NET уже вызвал у мирового сообщества Visual Basic-программистов множество реакций, и среди них немало негативных. На эту тему идут многочисленные дискуссии в Интернете. В частности, один из критиков нововведений, Карл Петерсон, создал Web-страницу под красноречивым названием "Visual Basic.NOT", где привел "неполный" (!) перечень расхождений (около 80 позиций) между Visual Basic 6.0 и Visual Basic.NET. Во всех этих обсуждениях довольно много эмоций ("Visual Basic.NET -- это уже не настоящий Basic", "нам не нужны ваши новшества" и т.п.), но за ними скрывается серьезный прагматичный аспект -- надежная миграция с одной версии на другую не будет обеспечена, код существующих приложений придется переписывать.

В свою очередь, Microsoft занимает пока твердую позицию, заявляя, что большинство Visual Basic-разработчиков одобряет изменения в Visual Basic.NET. И объясняет, что корпорация приняла трудное для себя решение о радикальной коррекции Visual Basic, понимая необходимость перехода от PC-ориентированной модели вычислений к Web-ориентированной.

Так или иначе, но сейчас мы наблюдаем самое сильное противостояние Basic-программистов с поставщиком инструментария за все время существования Visual Basic, причем раньше разработчики требовали нововведений, а сейчас протестуют против них. (Нечто похожее было в начале 90-х годов при переходе от MS Basic for DOS к Visual Basic for Windows. Тогда Microsoft более двух лет была вынуждена поддерживать оба направления, выпустив даже мертворожденный Visual Basic for DOS.) Чем закончится нынешнее противостояние, сказать трудно. Скорее всего, Microsoft будет решительно вести свою линию. Впрочем, стоит вспомнить историю пятилетней давности, когда, увидев негативную реакцию пользователей, корпорация решила продолжить выпуск Visual FoxPro (его очередная версия должна появиться и в нынешнем году).

Конечно, можно воспринимать будущие изменения как данность ("солнце всходит и заходит") и просто начать готовиться к ним. Но мне кажется, что эта тема вполне достойна для обсуждения профессиональными разработчиками. Вряд ли мы повлияем на позицию Microsoft, но для себя очень полезно понять некоторые аспекты физической реализации нововведений. Ведь вполне возможно, что для "смягчения" перехода на новую версию кому-то придется писать собственные Visual Basic Migration Tools, причем не только для себя, но и для коммерческого распространения.

Ниже мы рассмотрим ожидаемые нововведения и рекомендации, как уже сейчас нужно готовиться к переходу на Visual Basic.NET. По ходу дела я попробую расставить некоторые свои комментарии, но вначале хотелось бы отметить некоторые общие моменты.

1. Следует признать, что многие изменения синтаксиса в Visual Basic.NET очень полезны и их нужно было реализовать раньше (точнее, не допускать всяческих несуразностей изначально). Это касается совершенно неясного понятия Null, дубликатных функций типов String и Variant (например, Left$ и Left), дубликатных логических конструкций (Do и White), несоответствия свойств (элемент управления Label использует свойство Caption, которое по смыслу соответствует свойству Text всех остальных компонентов) и т.д.

2. Такое приведение синтаксиса языка в порядок, а также удаление явных рудиментов языка (Gosub/Return в случае Visual Basic) -- довольно обычное дело. Но вот как это делается, например, при модификации стандарта FORTRAN (раз в 7-10 лет): в очередном стандарте сразу публикуется список конструкций, которые, скорее всего, не попадут в следующую версию.

3. Модификация внутренних механизмов реализации тех или иных функций вполне понятна. Но мне кажется, что это можно было сделать в рамках традиционного синтаксиса Basic, не нарушая преемственности кода (речь тут идет о переносе ряда функций из внутренних библиотек во внешние объекты). Ведь по большому счету и раньше основная часть функций Visual Basic была реализована через Win API, а Visual Basic-операторы представляли собой просто удобный и безопасный (что очень важно) способ обращения к средствам Windows.

4. Изменение смысловой нагрузки одной и той же конструкции представляется непонятным и нарушающим простые принципы совместимости кода.

5. Самое "забавное" в нововведениях Visual Basic.NET -- Microsoft отказывается от вольностей в Visual Basic-программировании, которые сама же ввела и за которые всегда подвергалась критике со стороны профессионалов. Речь идет о широком использовании универсальных переменных типа Variant и неявного преобразования типов данных, установки свойств объектов по умолчанию и пр. Тем, кто не попался на удочку подобного "облегчения жизни" (а очевидных проблем, вытекающие из таких "послаблений", могли не видеть только новички от программирования), переходить на Visual Basic.NET будет гораздо проще.

Перенос проектов из Visual Basic 6.0 в Visual Basic.NET

Системы Visual Basic 6.0 и Visual Basic.NET могут быть установлены на одном компьютере и работать одновременно, точно так же, как и приложения, разработанные с помощью этих инструментов. Компоненты, написанные с помощью Visual Basic.NET, могут взаимодействовать с СОМ-компонентами, созданными в более ранних версиях Visual Basic. Например, можно подключить элемент управления ActiveX, реализованный в Visual Basic 6.0, к Windows-форме Visual Basic.NET; приложение Visual Basic.NET может использовать COM-объект Visual Basic 6.0. И, наоборот, -- к проекту Visual Basic 6.0 можно добавить ссылку на библиотеку Visual Basic.NET.

Visual Basic.NET не будет напрямую поддерживать совместимость с проектами Visual Basic 6.0. Но он содержит Upgrade Wizard (мастер обновления), который по шагам будет выполнять преобразование программы старого формата в новый проект Visual Basic.NET (начальный проект остается без изменений). Этот процесс односторонний -- проекты Visual Basic.NET нельзя открывать в Visual Basic 6.0.

В процессе обновления проектов выполняется модернизация синтаксических конструкций и замена Visual Basic 6.0 Forms на Windows Forms (последние имеют иную объектную модель, хотя и похожую во многом на Visual Basic 6.0 Forms).

Однако целый ряд возможностей и функций Visual Basic 6.0 в Visual Basic.NET в принципе не будет поддерживаться (например, некоторые виды проектов и элементов управления). Соответствующую модернизацию придется делать "руками".

В то же время Visual Basic.NET содержит ряд встроенных средств, реализацию которых ранее приходилось выполнять с помощью прикладного кода. Например, так это нужно делать для автоматической "привязки" положения кнопки к правому нижнему краю формы при изменении размеров последней. В Visual Basic.NET это решается с помощью установки нового свойства Anchor.

В процессе обновления проекта Visual Basic 6.0 мастер Visual Basic.NET сам находит подобные места потенциальной модификации, помечает их комментариями (с текстом, начинающимся словами TO DO) и формирует специальный "отчет обновления". Кроме того, каждый такой фрагмент кода отражается в новом окне Task List (список заданий), с помощью которого разработчик может быстро перемещаться по нужным компонентам проекта.

Конечно, было бы крайне желательно, чтобы протоколировались (комментарии, отчет) и все изменения, выполненные автоматически.

Качество существующего варианта Upgrade Wizard требует дополнительного изучения, и можно надеяться, что по мере доводки системы до окончательного релиза его функциональность будет повышаться (мы обсудим этот вопрос в последующих публикациях).

А теперь перейдем к советам.

Совет 1. Сначала перейдите к Visual Basic 6.0

Если вы работаете с Visual Basic версии 5.0 и ниже, то следует сначала преобразовать программы в проекты Visual Basic 6.0 (со всеми вытекающими отсюда задачами их доработки), а уже потом перейти к их адаптации для Visual Basic.NET.

Совет 2. Не спешите расставаться с Visual Basic 6.0

Вполне вероятно, что некоторые приложения будет выгоднее развивать и поддерживать в среде Visual Basic 6.0 (даже несколько лет!), чем переводить в Visual Basic.NET. Не говоря уже о том, преобразование сложных проектов в новую среду будет совсем не мгновенным.

Совет 3. Будьте внимательны при копировании фрагментов кода через буфер обмена

Такой прием часто применяется при работе с повторно используемыми фрагментами кода. Многие разработчики хранят подобные коллекции программ в различных хранилищах (начиная от текстовых файлов и заканчивая хранилищами Code Librarian), и перенос данных оттуда часто выполняется именно таким образом. Например, я порой использую подобный прием, когда нужно переписать нужную процедуру из старого проекта на Visual Basic 5 (и даже на Visual Basic 3) в новую программу. Понятно, что в этом случае нельзя ждать автоматического преобразования кода из Visual Basic 6.0 в Visual Basic.NET -- вся ответственность ложится на разработчика.

Если вы пользуетесь коллекцией повторно используемого кода, то нужно преобразовать ее в вариант Visual Basic.NET. Интересно, Microsoft сама сделает утилиту такого преобразования для хранилища Code Librarian или оставит эту задачу независимым разработчикам?

Совет 4. Внимательно изучите будущие новшества Visual Basic.NET

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

Совет 5. Максимально выносите логику обработки из модулей форм

Вообще говоря, это я рекомендую всегда, вне зависимости от перехода на Visual Basic.NET. Например, если у вас есть форма, которая содержит сколько-нибудь сложную логику, то имеет смысл подумать о создании специального BAS-модуля, куда можно перенести основные процедуры обработки данных. (Обычно процедуры создаются для реализации повторно используемых фрагментов кода, но тут как раз тот случай, когда полезно их применять и для линейного кода.) Причем речь может идти даже о двух-трех операторах из событийных процедур. Что же касается обычных процедур, то их однозначно нужно записывать в BAS-модули.

Пользу такого выделения логики уже давно поняли программисты, которые работают одновременно с Visual Basic и VBA -- несмотря на схожесть реализации программного интерфейса в этих двух системах, переносить программы без особых проблем (хотя все же проблемы есть!) удается только для модулей кода. А формы у них несовместимы. Поэтому бывает проще перерисовать в новой среде, адаптировать в ней минимальный код обработки и подгрузить готовый BAS-модуль.

Аналогичная картина будет при конвертации существующих Visual Basic Forms в Windows Forms и модификации Web Forms. Хотя Microsoft обещает максимально упростить этот переход, но очевидно, что стопроцентного автоматического преобразования не будет.

А если говорить о переносе приложений, то имеет смысл в более широком плане подумать о более четком разделении на интерфейс пользователя и бизнес-логику и выделении последней в виде автономных ActiveX-компонентов. Иными словами, речь может идти о выделении из единого приложения соответствующей библиотеки (или библиотек) объектов. Глядишь, какие-то из них пригодятся и для других программ.

Совет 6. Ориентируйтесь на работу с ASP.NET

Visual Basic 6.0 поддерживал три типа Интернет-приложений, основанных на использовании доступа через браузер: DHTML-приложения, документы ActiveX и приложения WebClass. Все эти три вида могут взаимодействовать с технологиями Visual Basic.NET.

Первые два типа приложений в Visual Basic.NET поддерживаться не будут, и их автоматического обновления для Visual Basic.NET не предусматривается. Лучший вариант - продолжать поддерживать их в Visual Basic 6.0, хотя, возможно, имеет смысл преобразовать документы ActiveX в пользовательские элементы управления.

WebClass-приложений также не будет, но будет реализован механизм их обновления в ASP.NET; правда, при этом потребуется внести ряд изменений вручную. (Мы уже писали ранее, что ASP.NET - это фактически объединение существующих технологий ASP и WebClass.)

Совет 7. Используйте ADO для работы с базами данных

Главная технология доступа к данным в Visual Basic.NET - ADO.NET, представляющая собой дальнейшее развитие существующей версии ADO. Старые средства -- DAO и RDO -- будут поддерживаться в Visual Basic.NET только на уровне кода (с некоторыми модификациями), но соответствующие элементы управления уже нельзя будет использовать. Таким образом, если ваши приложения применяют элементы управления DAO и RDO, то нужно либо поменять их на ADO, либо продолжать работать с ними в Visual Basic 6.0.

Совет 8. Не используйте свойства и методы по умолчанию

Visual Basic всегда отличался дурной манерой выделять "любимчика", используемого по умолчанию, из набора свойств или методов объекта. Например, для элемента управления Label код:

lblMyLabel = "Готовься к Visual Basic.NET"

сейчас работает, поскольку Caption - это как раз такое свойство по умолчанию для метки. Хотя правильнее было бы написать:

lblMyLabel.Caption = "Готовься к Visual Basic.NET"

В Visual Basic.NET для метки нужно вместо Caption использовать свойство Text (оно применяется для хранения содержимого в подобных элементах управления). Если же вы хотите непременно сократить усилия по написанию кода, то можно предложить такой вариант:

Dim obj As Object 
Set obj = frmMain.txtInput.Text 
Msgbox obj  ' напечатается содержимое текстового поля

Вместе с тем "параметризованные" свойства в Visual Basic.NET по-прежнему можно опускать. Например, "полный" код выглядит следующим образом:

Dim rs As ADODB.Recordset rs.Fields("CompanyName").Value = "Micro-soft"

В Visual Basic 6.0 последнюю строку можно записать так:

rs("CompanyName") = "Micro-soft"

В Visual Basic.NET можно сделать только такое сокращение:

rs("CompanyName").Value = "Micro-soft"

Мы видим, что пропущено "параметризованное" свойство Fields, но простое свойство Value должно быть указано.

Совет 9. Используйте раннее связывание

Как известно, в Visual Basic реализованы две технологии связывания компонентов проекта: ранее и позднее связывание. Приоритетное применение раннего связывания - это общая рекомендация при разработке приложений (позднее связывание лучше использовать, когда другого выхода нет или этого требуют условия задачи). На практике позднее связывание применяется тогда, когда сначала объявляется переменная типа Object, которая потом во время выполнения принимает значение конкретного класса или элемента управления.

Но имейте в виду, что для автоматического преобразования синтаксиса Upgrade Wizard должен знать точное значение объекта. Например, если, применяя конструкцию позднего связывания, вы напишете:

Dim obj As Object    ' неопределенный объект 
Set obj = Me.Label1 
obj.Caption = "НекийТекст"

то Upgrade Wizard не обновит последнюю строку, так как он ориентируется на начальное определение объекта. (Точно так же для этой строки не будет работать интеллектуальная подсказка и проверка синтаксиса при вводе.)

А если вы сразу опишете конкретный тип объекта (раннее связывание):

Dim obj As Label    ' объект Label 
Set obj = Me.Label1 
obj.Caption = "НекийТекст"

то Upgrade Wizard последнюю строку обновит:

obj.Text = "НекийТекст"

Совет 10. Не пугайтесь изменения синтаксиса процедуры Property

Как известно, процедура Property представляет собой парную конструкцию Get и Put примерно такого вида:

Property Get MyProperty () As Integer
  MyProperty = m_MyProperty
End Property Property Set MyProperty (NewValue As Integer)
  m_MyProperty = NewValue
End Property

Такое разнесение кода очень неудобно, в частности, потому что две конструкции окажутся в разных частях программного модуля. Теперь Property будет реализована в следующем виде (преобразование выполняется автоматически):

Property MyProperty () As Integer
  Get
    MyProperty = m_MyProperty
  End Get
  Set
    m_MyProperty = Value
  End Set
End Property

Совет 11. Не используйте прямые ссылки на элементы управления других форм

До сих пор все элементы управления на формах имели фиксированный статус Public. Соответственно, доступ к ним можно было получить из любого места проекта, например, следующим образом:

sTitle = frmSomeForm.txtTitle1.Text

Теперь можно будет обращаться к тем элементам управления, для которых в явном виде указан статус Public Shared.

Однако нужно отметить, что такой прямой метод доступа к внутренним компонентам формы (не только к элементам управления) - не лучшее решение. Гораздо изящнее использование специальных процедур -- свойств формы.

Предположим, на некоторой форме имеется набор из пяти кнопок-переключателей (например, для выбора типа отчета), и вам нужно из внешнего BAS-модуля определить их состояние. Можно написать такой код:

For nIndex = 0 To 5
  If frmOptions.optBlock(nIndex) Then
    FormatNumber = nIndex: Exit for
  End if
Next

Но этот вариант не очень удачен. Возможно, позднее вы захотите изменить количество переключателей или их имена, либо заменить блок переключателей на список. Тогда вам придется менять код не только внутри формы, но и во всех(!) местах проекта, где встречается обращение к ней. Такие проблемы легко решить, создав для формы свойство iNumber и написав для него следующий код:

Public Property Get FormatNumber() As Long
  For nIndex = 0 To 4
    If frmOptions.optBlock(nIndex) Then
      FormatNumber = nIndex: Exit for
    End if
  Next
End Property

Тогда выбор типа отчета будет выполняться строкой:

nMyNumber = frmOptions.FormatNumber

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

Public Property Get FormatNumber() As Long
   FormatNumber = lst.ListIndex
End Property

Совет 12. Готовьтесь к изменению типов целочисленных переменных

До сих пор в Visual Basic было два типа целочисленных переменных со знаком -- 16- (Integer) и 32-разрядные (Long). В Visual Basic.NET к ним прибавится 64-разрядный целочисленный тип. Его появление в условиях полного перехода на 32-разрядную архитектуру и ожидания 64-разрядных ПК вполне естественно и, наверное, необходимо для решения практических задач.

Но чтобы немного остудить радость разработчиков, Microsoft решила добавить "ложку дегтя", переименовав традиционные ключевые слова для обозначения целых переменных:

Лично я не вижу смысла в такой перестановке, кроме объяснения типа "чтобы разработчикам жизнь медом не казалась". Microsoft объясняет это тем, что "естественная" переменная для современных компьютеров - 32-разрядная. Но довод этот весьма слаб -- Integer существует как 16-разрядная переменная на протяжении более сорока последних лет (речь идет не только о Visual Basic) совершенно независимо от типов процессора (от 4- до 64-разрядных). Так что тут можно увидеть лишь вызов традициям.

Разумеется, Upgrade Wizard сделает нужное обновление и вместо

Dim x As Integer
Dim y As Long

запишет в проект Visual Basic.NET:

Dim x As Short 
Dim y As Integer

Но все же легко представить себе, насколько у разработчиков прибавится головной боли, тем более если учесть, что многим из них понадобится одновременно работать с разными версиями Visual Basic.

Вместе с тем хотелось бы обратить внимание, что Microsoft упорно не желает вводить в Visual Basic крайне необходимые в работе беззнаковые целые числа. А значит, разработчикам по-прежнему потребуется прибегать к хитрым кодам для выделения, например, байта со знаковым разрядом.

Говоря об использовании разных типов целых переменных, надо еще отметить следующее. Во времена 16-разрядных компьютеров (процессор 286) использование Long (здесь термины используются в контексте Visual Basic 6.0) приводило не только к увеличению требуемого объема памяти, но и к снижению скорости выполнения операций (в обоих случаях в два раза). В 32-разрядных системах скорость операций для обоих типов переменных - Integer и Long - одинакова. Исключение составляют только ранние 32-разрядные модели процессоров AMD K5 и K6, которые имели отдельные блоки обработки коротких переменных (Intel полностью отказалась от 8/16-разрядных блоков при переходе на архитектуру P6).

Совет 13. Готовьтесь отказаться от типа данных Currency

В Visual Basic.NET не будет поддерживаться тип Currency -- вместо него предлагается использовать тип Decimal. Однако, как конкретно применить эту рекомендацию, пока не очень понятно. Дело в том, что Currency -- это восьмибайтовая переменная, которая содержит вещественное число в формате с фиксированной десятичной запятой (четыре десятичных знака после запятой). Она специально предназначена для хранения и обработки денежных единиц, хотя некоторые разработчики экономических задач считают точность и диапазон этого типа данных недостаточным для российских условий.

О типе Decimal пока доподлинно известно лишь то, что эта переменная занимает 12 байтов и хранит вещественные числа с фиксированной запятой. Но как практически работает арифметика для этих данных и как определяется положение десятичной запятой -- не очень понятно. Дело в том, что тип Decimal существует в Visual Basic 6.0 лишь "виртуально" -- объявить такую переменную нельзя. В Справке говорится, что для создания переменной Decimal можно воспользоваться типом Variant и функцией CDec, но результаты реальных тестов расходятся с описанием. Тем не менее в Visual Basic.NET обещано появление стандартного встроенного типа Decimal.

Совет 14. Скорее откажитесь от Variant

Типа данных Variant больше не будет. Программисты наконец-то освободятся от "иглы", на которую их пытаются "посадить" начиная с Visual Basic 2.0 (в Visual Basic 3.0 этот тип стал использоваться по умолчанию). На замену ему придет тип Object, которые в Visual Basic 6.0 используется только для ссылок на объект. Теперь Object будет применяться и для ссылок на простые переменные, но, кажется, в Visual Basic.NET манипуляции с автоматическим преобразованием данных будут сильно ограничены.

Бездумное использование типа данных Variant -- одно характерных проявлений плохого стиля программирования. И дело тут не в том, что нарушаются классические принципы программирования -- четкий контроль за типами данных и процедурами их преобразования из одного типа в другой. Просто это становится причиной разнообразных проблем при разработке приложений.

На самом деле такой универсальный тип данных нужен для некоторых специальных применений, например, для передачи в процедуру аргументов произвольного типа, но, как любое "острое" оружие, он требует очень осторожного обращения. Ведь декларируемое достоинство Variant -- автоматическое преобразование данных -- несет в себе потенциальную угрозу: непрогнозируемость результата (не говоря уже о снижении эффективности кода из-за преобразований, которых можно легко избежать). Например, попробуйте "вручную" определить результат работы такой простой конструкции:

Dim a, b 
a = #12/01/2001# 
b = "15,6" + d + 10 + True & True 
Msgbox b

Самое удивительное, что с точки зрения синтаксиса Visual Basic подобный абсурдный код допустим.

Можно вспомнить, что появление типа Varianl в свое время сопровождалось восторженными оценками ИТ-комментаторов ("Наиболее важным нововведением Visual Basic 2.0 является "варьируемый" тип данных"). Но сейчас даже Microsoft поняла, что ситуация с преобразованием данных выходит из под контроля и решила вернуться к старым добрым принципам построения языков программирования.

Совет 15. Используйте только явное описание типов данных

Еще одно изменение Visual Basic.NET несет нам хорошие и не очень хорошие новости. Хороших новостей две. Первая -- типы всех переменных должны быть описаны в явном виде (в Visual Basic 6.0 по умолчанию -- при отсутствии описания As... -- устанавливался тип Variant). Вторая -- будет реализовано давно необходимое (и существующее в других языках) групповое описание типов данных, например:

Dim strFirstString, strSecondString As String

Отныне эта строка будет означать, что обе переменные -- строковые, имеют тип String.

Но как раз здесь кроется и серьезная проблема -- ведь точно такая же строка в Visual Basic 6.0 означала, что strFirstString имеет тип Variant. (О чем и говорилось выше -- один и тот же код синтаксически правилен, но имеет разный смысл в различных версиях Visual Basic). Соответственно, код

Dim strFirstString, strSecondString As String 
strFirstString = 1.2

в Visual Basic 6.0 работает , а в Visual Basic.NET -- нет.

Совет 16. Забудьте о Def

Это новшество непосредственно связано с описанным выше. В Visual Basic (наследство древних версий Basic) имелась группа операторов -- DefBool, DefByte, DefInt и т.д., которая позволяла устанавливать тип переменной или функции по первой букве идентификатора (если не указан тип в явном виде). Это было довольно удобно для группового описания типов. Например:

DefInt I-N

означало, что оператор

Dim iMyValue, nYourValue

объявляет переменные типа Integer. Такой прием часто использовали программисты на FORTRAN при переходе в Basic (в очень старые времена в FORTRAN переменные, начинающиеся на I-N, автоматически считались целочисленными).

Но все же использование оператора Def всегда имело один подводный камень, и поэтому его удаление из синтаксиса можно считать полезным. Ведь данное объявление размещается в начале модуля и распространяется только на его переменные. Соответственно, при переносе программного фрагмента из модуля в модуль (например, процедуры) интерпретация кода зависела от установок конкретного модуля -- наличие потенциальных ошибок в этом случае совершенно очевидно.

Впрочем, если разработчик использовал одинаковый набор операторов Def во всех своих программах, это позволяло быстро ориентироваться в типах переменных, не изучая соответствующих объявлений. Однако то же самое можно получить, просто приняв для себя строгую систему префиксов переменных.

Вместе с тем следует подчеркнуть, что в Visual Basic.NET сохранена возможность использовать суффиксы для определения типов данных (но только для тех типов, которые перешли в наследство от MS Basic/DOS):

Это значит, что описание

Dim FirstValue$, SecondValue%

эквивалентно

Dim FirstValue As String, SecondValue As Integer

Совет 17. Замените вычисляемый Goto/Gosub на Select

Конструкция вычисляемого Goto/Gosub - типичный рудимент Basic 60-х годов. Многие Visual Basic-программисты ее вообще не знают и правильно делают (само использование меток внутри процедуры -- это плохой стиль программирования). Тем не менее следует помнить, что конструкция типа

On xValue Goto 100, 200, 300, 400

легко меняется на

Select Case x
  Case 1
     ' тут выполняется код для метки 100
  Case 2
... End Select

Совет 18. Замените GoSub/Return на Call Sub

Конечно, это тоже рудимент старинного Basic, но то, что о нем многие забыли, в данном случае не очень хорошо. В результате довольно часто встречаются такие конструкции кода:

Select Case SomeValue
  Case 0
    MyString$ = SomeGirl$ & "+" & SomeBoy$
    MsgBox MyString$
  Case 1
    MyString$ = SomeGirl$ & "-" & SomeBoy$
    MsgBox MyString$
  ...
End Select

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

Select Case SomeValue
  Case 0: MyString$ = MyFunction$(SomeGirl$, "+", SomeBoy$)
  Case 1: MyString$ = MyFunction$(SomeGirl$, "-", SomeBoy$)
End Select

Однако при этом не исключено снижение быстродействия (передача параметров занимает много времени). Вот как раз тут и можно эффективно использовать конструкцию GoSub:

Select Case SomeValue
  Case 0: MyDel$= "+": GoSub MyFunction
  Case 1: MyDel$= "-": GoSub MyFunction
End Select
... MyFuction:
    MyString$ = SomeGirl$ & MyDel$ & SomeBoy$
    MsgBox MyString$
Return

Здесь видно, что GoSub/Return - очень удобная (к тому же эффективная с точки зрения ресурсов -- памяти и времени выполнения) конструкция для реализации повторно используемого кода внутри процедуры с применением ее внутренних переменных.

Теперь Gosub/Return исключается из Visual Basic.NET, и я рекомендую заменить ее обращением к подпрограмме статуса Private, с использованием переменных уровня модуля. Это может выглядеть так:

' объявление переменных на уровне модуля: Dim  MyString$, 
SomeGirl$, SomeBoy$ 
'==============
Select Case SomeValue
  Case 0: Call MySub$("+")
  Case 1: Call MySub$("-")
End Select
Private Sub MySub (Mydel$)
    MyString$ = SomeGirl$ & MyDel$ & SomeBoy$
    MsgBox MyString$
End Sub

Код будет почти таким же эффективным, как с применением GoSub/Return (минимум передаваемых параметров).