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

https://stackoverflow.com/questions/222370

03-07-2019
|

Вопрос

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

Я хотел бы дать совет о том, следует ли рекомендовать им всегда включать Вариант Строгий или нет.

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

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

Решение

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

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

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

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

Другие советы

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

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

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

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

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

ДА!!!!

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

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

добавлен

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

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

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

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

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

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

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



	
		
			Лицензировано под: CC-BY-SA с атрибуция
			Не связан с StackOverflow