Я готовлю курс по Visual Basic 2005, ориентированный на программистов Visual Basic 6, переходящих на платформу .NET.
Я хотел бы получить совет о том, рекомендовать ли им всегда включать Option Strict или нет.
Я работал исключительно с языками программирования в стиле C, в основном с Java и C #, поэтому для меня явное приведение - это то, чего я всегда ожидал. необходимо сделать, так как это никогда не было вариантом.
Однако я признаю ценность работы с языком, который имеет встроенную поддержку позднего связывания, потому что не нужно быть чрезмерно явным насчет типов в коде действительно экономит время. Это дополнительно подтверждается популярным распространением языков с динамической типизацией даже на платформе .NET с динамической языковой средой выполнения.
Имея это в виду, следует поощрять кого-то, кто впервые приближается к .NET с использованием VB.NET и с опытом работы с VB6, понять, что приходится работать с временем компиляции проверка типа, потому что это «лучшая практика» в среде CLR? Или можно продолжать пользоваться преимуществами позднего связывания?
Option Strict On и .NET для программистов VB6
Ответы (8)
Да! Option Strict определенно является лучшей практикой для .Net. Подчеркните, что .Net по своей сути является строго типизированной платформой и будет таковой до тех пор, пока DLR не будет полностью поддерживаться. За некоторыми исключениями, для каждого Dim и Function должен быть объявлен явный тип, соответствующий им. Такие вещи, как LINQ или Boo и JScript, являются исключениями, подтверждающими правило.
Вот еще несколько моментов, на которые стоит обратить внимание. Я уверен, что вам все это хорошо известно, но мне приходилось работать и поддерживать много кода VB.Net, написанного бывшими VB6ers, так что это что-то вроде больного места для меня:
- Не используйте старые строковые функции:
LEN(),REPLACE(),TRIM()и т. Д. - Венгерские бородавки больше не рекомендуются.
oMyObjectиsMyStringне кошерные. Если они не верят, покажите им ссылку в Рекомендациях Microsoft по дизайну ты. - Убедитесь, что они узнали о новых _8 _ / _ 9_ логических операторах.
- ПАРАМЕТРИЗОВАННЫЕ ЗАПРОСЫ и современный ADO.Net. Не могу этого достаточно подчеркнуть. Им больше никогда не придется звонить
CreateObject(). - Область видимости работает в .Net по-другому (и это более важно), чем в VB6. В VB.Net все еще есть модули, но теперь они больше похожи на статический класс. Важно понимать, чем отличается разработка в реальной объектно-ориентированной среде, в отличие от частичной поддержки ООП, предоставляемой VB6. Больше нет веской причины позволять методам работать до безбожной длины.
- Убедитесь, что они получили введение в Generics и Interfaces (включая
IEnumeralbe(Of T)), и узнают, почему они никогда не должны снова использоватьArrayList.
Я мог бы продолжить, но я просто укажу вам на скрытые возможности VB.Net Вопрос, чтобы закрыть эту тираду.
Option Infer On на помощь (правда, только для Dims).
- person Konrad Rudolph; 21.10.2008
MsgBox).
- person Konrad Rudolph; 21.10.2008
Время, потраченное на разработку с включенным Option Strict, в дальнейшем значительно сэкономит вам время на отладку.
Option Strict очевидно, не может заменить хорошее модульное тестирование - но не наоборот. Хотя модульное тестирование может обнаруживать те же ошибки, что и Option Strict, это означает, что в модульных тестах нет ошибок, что модульное тестирование выполняется часто и рано и т. Д.
Написание хороших модульных тестов не всегда тривиально и требует времени. Однако компилятор уже реализует некоторые тесты - в виде проверки типов. По крайней мере, это экономит время. Скорее всего, это сэкономит много времени и денег (по крайней мере, иногда), потому что ваши тесты были ошибочными / не охватывали все случаи / забыли учесть изменения в коде.
Подводя итог, нет никакой гарантии, что ваши модульные тесты верны. С другой стороны, есть надежная гарантия, что проверка типов, выполняемая компилятором, правильная или, по крайней мере, что его сбои (непроверенная ковариация массива, ошибки с циклическими ссылками…) хорошо известны и хорошо задокументированы.
Подведем еще один итог: Да, Option Strict On, безусловно, лучшая практика. На самом деле, я годами работал в онлайн-сообществах, подобных этому. Когда кому-то требовалась помощь по коду, для которого явно не было Option Strict включено, мы вежливо указывали на это и отказывались оказывать дальнейшую помощь, пока это не будет исправлено. Это экономит так много времени. Часто после этого проблема исчезла. Это в некоторой степени аналогично использованию правильного HTML при обращении за помощью на форуме поддержки HTML: недопустимый HTML может работать, но опять же, он может не работать и быть причиной проблем. Поэтому многие профессионалы отказываются от помощи.
ДА!!!!
На мой взгляд, и как разработчик, и как преподаватель ДА.
Лучше всего с самого начала выработать хорошие привычки, это значительно упрощает весь процесс, и Option Strict - один из тех элементов, которые, на мой взгляд, НЕОБХОДИМЫ.
добавлено
Существует буквально масса причин, по которым можно было бы перечислить почему, но главное в том, что это лучшая практика, а при обучении новому языку важно обучать этим лучшим методам с самого начала.
Помните, что здесь два уровня.
Параметр Явный Параметр Строгий
Основное различие между ними заключается в том, что Option Strict отключает автоматическое преобразование различных типов данных в VB. Вы должны явно использовать CType или другую функцию преобразования данных, чтобы присвоить переменной другой тип.
Я использую VB с версии 1.0, и, хотя я понимаю суть этого, я думаю, что Strict особенно усердно работает с объектами, которые реализовали или унаследовали разные интерфейсы и классы.
Сначала я бы начал со Строгого, и если он начнет мешать вам, перейдите к Явному. Но никогда не выключайтесь одновременно, в этом кроется безумие и чрезмерное время на отладку.
За годы работы с VB я в значительной степени использовал Double для всех переменных с плавающей запятой. Таким образом вы избежите многих проблем с округлением и потерей точности. В VB6 я использовал до тех пор, пока это было 32-битное целое число, но Integer работает в .NET так же хорошо, как и с Int32. Я также рекомендую использовать Int32, Int16 и т. Д. Вместо Integer, Long и т. Д. На случай, если Microsoft когда-либо решит переопределить эти ключевые слова.
Я собираюсь не согласиться с RS Conley (очень необычно). Мои любимые гуру VB6 - Франческо Балена, Дэн Эпплман - всем не нравилось автоматическое преобразование VB6, и они в пользу Option Strict в .NET. Многие опытные программисты VB6 знают автоматическое преобразование как «принуждение злого типа» (pdf) и будет рад включить Option Strict.
Иногда лучше использовать один небольшой модуль без Option Strict, чтобы избежать большого количества сложного кода отражения. Но это исключение, подтверждающее правило.
Учитывая представление Боэма о том, что устранение проблемы на более раннем этапе цикла разработки требует наименьших затрат ресурсов, я поклонник любого инструмента, который помогает разработчикам «сделать все правильно» как можно раньше. По этой причине я сторонник таких вещей, как IntelliSense, который является одновременно средством повышения эффективности и инструментом, который помогает вам реализовать рабочий код на более ранних этапах цикла. (Работает, но не обязательно правильно.)
По этой причине я также поддерживаю использование Option Strict как способ помочь избежать ошибок и последующих исправлений «во время разработки».
Если вы привыкли проверять свои типы, то, вероятно, захотите, чтобы опция была строго включена. ее отключение может иметь преимущества, но если ваш мозг не настроен на обнаружение ошибок, на которые компилятор обычно жалуется, то я бы посоветовал оставить его включенным. Я много работал с VB.Net, и должен сказать, что, хотя большую часть времени я работаю со строгим отключением параметров, я видел множество ситуаций, когда его включение предотвратило бы довольно много ошибки.
