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

Ответ 1

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

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

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

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

Ответ 2

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

Ответ 3

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

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

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

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

Ответ 4

ДА!!!!

По-моему, как разработчик, так и преподаватель колледжа ДА.

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

добавлен

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

Ответ 5

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

Опция Явная Вариант Строгий

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

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

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

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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