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

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

ДА!!!!

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

Лучше всего с самого начала выработать хорошие привычки, это значительно упрощает весь процесс, и Option Strict - один из тех элементов, которые, на мой взгляд, НЕОБХОДИМЫ.

добавлен

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

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

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

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

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

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

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

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

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

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

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

Вариант Явный Вариант Строгий

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

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

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

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

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

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

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

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