Option Strict On и .NET для программистов VB6

Question

Я готовлю класс по Visual Basic 2005, предназначенный для программистов Visual Basic 6, переходящих на платформу .NET.

Я хотел бы дать несколько советов о том, рекомендовать ли им всегда включать Option Strict или нет.

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

Имея это в виду, если кто-то, кто впервые обращается к .NET с использованием VB.NET и имеет опыт работы с VB6, должен прийти к мысли о необходимости работать с проверкой типов во время компиляции , потому что это «лучшая практика» в CLR? Или это нормально, чтобы продолжать пользоваться преимуществами позднего связывания?

Answer 1

Да! Option Strict - определенно лучшая практика с .Net. Подчеркните, что .Net по своей сути является строго типизированной платформой, и будет работать до тех пор, пока DLR не будет полностью поддерживаться. За некоторыми исключениями, каждый Dim и Function должен иметь явный тип, объявленный для его использования. Такие вещи, как LINQ или Boo и JScript являются исключениями, которые подтверждают правило.

Вот некоторые другие вещи, на которые следует обратить внимание. Я уверен, что вы хорошо знаете обо всем этом, но мне пришлось поработать с большим количеством кода VB.Net, написанного бывшими VB6ers, и поэтому для меня это больное место:

• Не используйте старые строковые функции: LEN(), REPLACE(), TRIM() и т. Д.
• Венгерские бородавки больше не рекомендуются. oMyObject и sMyString не кошерные. Покажите им ссылку в Руководстве по проектированию Microsoft , если они вам не верят.
• Убедитесь, что они узнают о новых AndAlso / OrElse логических операторах
• ПАРАМЕТРИРОВАННЫЕ ЗАПРОСЫ и современные ADO.Net. Не могу подчеркнуть это достаточно. Им больше никогда не нужно звонить CreateObject().
• Scope работает по-другому (и более важно) в .Net, чем в VB6. В VB.Net все еще есть модули, но теперь они больше похожи на статический класс. Важно понимать, чем отличается разработка в реальной объектно-ориентированной среде от частичной поддержки ООП, предоставляемой VB6. Больше нет веской причины позволять методам работать безбожно.
• Убедитесь, что они знакомятся с Generics и Interfaces (включая IEnumeralbe(Of T)), и узнайте, почему им никогда не следует использовать ArrayList снова.

Я мог бы продолжать, но я просто укажу вам на Скрытые возможности VB.Net Вопрос, чтобы закрыть эту напыщенную речь.

Answer 2

Время, потраченное на разработку с включенной Option Strict, сэкономит вам огромное количество времени на отладку в дальнейшем.

Answer 3

Option Strict, очевидно, не может заменить хорошее юнит-тестирование, но и наоборот. В то время как модульное тестирование может обнаруживать те же ошибки, что и Option Strict, это означает, что в модульных тестах ошибок нет, что модульное тестирование проводится часто и рано, и т. Д. ...

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

Подводя итог, нет гарантии, что ваши юнит-тесты верны. С другой стороны, существует строгая гарантия того, что проверка типов, выполняемая компилятором, является правильной или, по крайней мере, ее сбои (непроверенная ковариация массива, ошибки с циклическими ссылками…) хорошо известны и хорошо документированы.

Еще один итог: Да, Option Strict On - определенно лучшая практика. На самом деле, я годами работал в таких онлайн-сообществах, как этот. Всякий раз, когда кому-то требовалась помощь по коду, в котором явно не было включено Option Strict, мы вежливо указывали на это и отказывались оказывать дальнейшую помощь, пока это не будет исправлено. Это экономит так много времени. Часто проблема исчезла после этого. Это в некоторой степени аналогично использованию правильного HTML при обращении за помощью на форуме поддержки HTML: недействительный HTML может работать, но, опять же, это может и не быть причиной проблем. Поэтому многие профессионалы отказываются помогать.

Answer 4

ДА !!!!

На мой взгляд, как разработчик, так и преподаватель колледжа ДА.

Лучше всего начать с хороших привычек с самого начала, это значительно облегчает весь процесс, и Option Strict является одним из тех элементов, который, на мой взгляд, является элементом NEEDED.

добавил

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

Answer 5

Помните, что здесь есть два уровня.

Параметр Явный Вариант строгий

Основное различие между ними заключается в том, что Option Strict отключает автоматическое преобразование VB разных типов данных. Вы должны явно использовать CType или другую функцию преобразования данных, чтобы назначить переменную другому типу.

Я использую VB с 1.0, и хотя я вижу смысл этого, я думаю, что Строгий чрезмерно усердно работает с объектами, которые реализовали или унаследовали различные интерфейсы и классы.

Сначала я бы начал со Strict, а если он начал мешать вам, то выпал бы до Explicit. Но никогда не выключайте оба, так кроется безумие и чрезмерное время отладки.

За годы работы с VB я в значительной степени использовал Double для всех переменных с плавающей запятой. Таким образом вы избежите многих проблем с округлением и потерей точности. В VB6 я использовал пока 32-битное целое число, но Integer работает так же хорошо в .NET, как и Int32. Я также рекомендую использовать Int32, Int16 и т. Д. Вместо Integer, Long и т. Д. На случай, если Microsoft когда-нибудь решит переопределить эти ключевые слова.

Answer 6

Я собираюсь не согласиться с RS Conley (очень необычно). Моим любимым гуру VB6 - Франческо Балена, Дэн Эпплман - всем не нравилось автоматическое преобразование VB6, и они в поддерживают из Option Strict в .NET Многие опытные программисты на VB6 знают автоматическое преобразование как «принуждение к злому типу» ( pdf ) и будут рады включить Option Strict.

Иногда лучше использовать один маленький модуль без Option Strict, чтобы избежать большого количества сложного кода отражения. Но это исключение, которое подтверждает правило.

Answer 7

Учитывая мнение Бема о том, что решение проблемы на ранних этапах цикла разработки потребляет наименьшее количество ресурсов, я являюсь поклонником каждого инструмента, который помогает разработчикам "сделать все правильно" как можно раньше. По этой причине я являюсь сторонником таких вещей, как IntelliSense, который является одновременно повышением эффективности, а также инструментом, который помогает вам реализовать рабочий код на ранних этапах цикла. (Работает, но не обязательно правильно.)

По этой причине я также поддерживаю использование Option Strict как способа помочь избежать ошибок и последующих исправлений глубоко во «времени разработки».

Answer 8

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