А ти готовий до Visual Basic.NET? , ASP, Програмування, статті

Як давно відомо всім Visual Basic-розробникам, в кінці нинішнього року очікується нова версія Visual Basic, яка повинна була мати порядковий номер 7.0, але несподівано отримала ім’я власне -. NET. Така зміна позначення версій є досить символічною – судячи з усього, гряде саме рішуче оновлення цієї популярної системи програмування за всі 10 років її існування … Як давно відомо всім Visual Basic-розробникам, в кінці нинішнього року очікується нова версія Visual Basic, яка повинна була мати порядковий номер 7.0, але несподівано отримала ім’я власне -. NET. Така зміна позначення версій є досить символічною – судячи з усього, гряде саме рішуче оновлення цієї популярної системи програмування за всі 10 років її існування (Visual Basic 1.0 з’явився в 1991 р.). Так що цілком імовірно, що чергова версія через пару років буде вже називатися Visual Basic.NET 2.0 …

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


* Андрій Колесов,
“В очікуванні Visual Studio.NET”, Byte / Росія № 1/2001.

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 вирішила додати “ложку дьогтю”, перейменувавши традиційні ключові слова для позначення цілих змінних:

Цілі змінні Visual Basic 6.0 Visual Basic.NET
16-розрядні Integer Short
32-розрядні Long Integer
64-розрядні Long

Особисто я не бачу сенсу в такій перестановці, крім пояснення типу “Щоб розробникам життя медом не здавалася”. 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 змінні, що починаються на IN, автоматично вважалися цілочисельними).

Але все ж використання оператора Def завжди мало один підводний камінь, і тому його видалення з синтаксису можна вважати корисним. Адже дане оголошення розміщується на початку модуля і поширюється тільки на його змінні. Відповідно, при перенесенні програмного фрагмента з модуля в модуль (наприклад, процедури) інтерпретація коду залежала від установок конкретного модуля – наявність потенційних помилок в цьому випадку абсолютно очевидно.

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

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

Суфікс Тип змінної
$ String
% Integer
& Long
! Single
# Double
@ Currency (в Visual Basic.NET не підтримується)

Це означає, що опис

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 (Мінімум переданих параметрів).

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*