Opción Strict On y .NET para programadores VB6

https://stackoverflow.com/questions/222370

03-07-2019
|

Pregunta

Estoy preparando una clase sobre Visual Basic 2005 dirigida a programadores de Visual Basic 6 que migran a la plataforma .NET.

Me gustaría un consejo sobre si recomendarlos para habilitar siempre Option Strict o no.

He trabajado exclusivamente con lenguajes de programación de estilo C, principalmente Java y C #, por lo que para mí transmisión explícita es algo que siempre espero que tenga que hacer, ya que nunca ha sido una opción.
Sin embargo Reconozco el valor de trabajar con un lenguaje que tiene soporte incorporado para enlace tardío , porque no tener que ser excesivamente explícito sobre los tipos en el código realmente ahorra tiempo. Esto se demuestra con la difusión popular de lenguajes dinámicos de tipo , incluso en la plataforma .NET con Dynamic Language Runtime.

Con esto en mente, si alguien que se acerca a .NET por primera vez usando VB.NET y con antecedentes de VB6 debe alentarse a tener la mentalidad de tener que trabajar con la verificación de tipos en tiempo de compilación porque esa es la "mejor práctica" en el CLR? ¿O es "OK" para seguir disfrutando de los beneficios de la fijación tardía?

Solución

¡Sí! Option Strict es definitivamente una mejor práctica con .Net. Haga hincapié en que .Net es, en esencia, una plataforma fuertemente tipada, y lo será hasta que el DLR sea más completamente compatible. Con pocas excepciones, cada Dim y Function debe tener un tipo explícito declarado para acompañarlo. Cosas como LINQ o Boo y JScript son las excepciones que prueban la regla.

Aquí hay algunas otras cosas para señalar. Estoy seguro de que es muy consciente de todo esto, pero he tenido que trabajar y mantener una gran cantidad de código VB.Net escrito por ex VB6ers, por lo que este es un punto doloroso para mí:

No utilice las funciones de cadena antiguas: LEN () , REPLACE () , TRIM () , etc.
Las verrugas húngaras ya no se recomiendan. oMyObject y sMyString no son kosher. Muéstreles la referencia en Directrices de diseño de Microsoft si no creen usted.
Asegúrese de que conozcan los nuevos operadores lógicos AndAlso / OrElse
CONSULTAS PARAMETERIZADAS y ADO.Net moderno. No puedo enfatizar eso lo suficiente. Nunca deberían necesitar llamar a CreateObject () nuevamente.
Scope funciona de manera diferente (y es más importante) en .Net que en VB6. VB.Net todavía tiene módulos, pero ahora son más análogos a una clase estática. Es importante comprender cómo el desarrollo en un entorno real orientado a objetos puede ser diferente, a diferencia del soporte parcial de OOP proporcionado por VB6. Ya no hay una buena razón para permitir que los métodos se ejecuten a longitudes impías.
Asegúrese de que obtengan una introducción a Generics e Interfaces (incluyendo IEnumeralbe (Of T) ), y aprenda por qué nunca deberían usar una ArrayList nuevamente.

Podría continuar, pero solo te señalaré las Características ocultas de VB.Net Pregunta para cerrar esta diatriba.

Otros consejos

El tiempo dedicado al desarrollo con la opción Option Strict le ahorrará una enorme cantidad de tiempo de depuración más adelante.

Option Strict obviamente no puede reemplazar una buena prueba de unidad & # 8211; pero tampoco al revés. Si bien las pruebas unitarias pueden detectar los mismos errores que Option Strict , esto implica que no hay ningún error en las pruebas unitarias, que las pruebas unitarias se realizan con frecuencia y de manera anticipada, etc. & # 8230 ;.

Escribir buenas pruebas unitarias no siempre es trivial y lleva tiempo. Sin embargo, el compilador ya implementa algunas de las pruebas & # 8211; en forma de verificación de tipo. Por lo menos, esto ahorra tiempo. Lo más probable es que esto ahorre mucho tiempo y dinero (al menos ocasionalmente) porque sus pruebas fueron erróneas / no cubrieron todos los casos / olvidó dar cuenta de los cambios en el código.

Para resumir, no hay garantía de que las pruebas de su unidad sean correctas. Por otro lado, hay una fuerte garantía de que la verificación de tipo realizada por el compilador es correcta o al menos que sus fallas (covarianza de matriz no verificada, errores con referencias circulares & # 8230;) son bien conocidas y están bien documentadas.

Otro resumen: Sí, Option Strict On es definitivamente la mejor práctica. De hecho, he trabajado durante años en comunidades en línea como esta. Cada vez que alguien necesitaba ayuda sobre un código que obviamente no tenía habilitado Option Strict , lo señalamos cortésmente y nos negamos a brindar más ayuda hasta que se solucione. Ahorra mucho tiempo. A menudo, el problema desapareció después de esto. Esto es algo análogo al uso de HTML correcto cuando se solicita ayuda en un foro de soporte de HTML: HTML no válido podría funcionar, pero, de nuevo, podría no ser y ser la causa de los problemas. Por lo tanto, muchos profesionales se niegan a ayudar.

¡SÍ!

En mi opinión, tanto como desarrollador como instructor universitario SÍ.

Es mejor comenzar con los buenos hábitos desde el principio, hace que todo el proceso sea mucho más fácil, y Option Strict es uno de esos elementos que, en mi opinión, es un elemento NECESARIO.

añadido

Hay literalmente toneladas de razones que podrían enumerarse por qué, pero la clave es que es una mejor práctica, y cuando se enseña un nuevo idioma, es clave enseñar esas mejores prácticas desde el principio.

Recuerda que hay dos niveles aquí.

Opción explícita Opción estricta

La principal diferencia entre los dos es que Option Strict deshabilita la conversión automática de VB de diferentes tipos de datos. Debe usar explícitamente CType u otra función de conversión de datos para asignar una variable a otro tipo.

He estado usando VB desde 1.0 y, aunque puedo ver el punto de esto, creo que Strict es demasiado celoso paritcularmente cuando se trata de objetos que han implementado o heredado diferentes interfaces y clases.

Comenzaría con Strict al principio y si comienza a interponerse en tu camino, luego desplázate a Explícito. Pero nunca se apaguen los dos, de esa manera se encuentra la locura y el tiempo de depuración excesivo.

Con los años con VB utilizo Double para todas las variables de punto flotante. De esta forma, evita muchos problemas de redondeo y pérdida de precisión. En VB6 usé siempre que era un entero de 32 bits, pero Integer funciona igual de bien en .NET que en Int32. También recomiendo usar Int32, Int16, etc. en lugar de Integer, Long, etc. en caso de que Microsoft decida redefinir esas palabras clave.

Voy a estar en desacuerdo con RS Conley (muy inusual). A mis gurús favoritos de VB6, Francesco Balena, Dan Appleman, no les gustó la conversión automática de VB6, y son en favor de Option Strict en .NET. Muchos programadores experimentados de VB6 conocen la conversión automática como "coerción de tipo maligno". ( pdf ), y estará encantado de encender Option Strict .



 En ocasiones es mejor usar un módulo pequeño sin  Option Strict , para evitar muchos códigos de reflexión complicados. Pero esa es la excepción que prueba la regla.



	
		
	
	
			 Dada la noción de Boehm de que solucionar un problema al principio del ciclo de desarrollo consume la menor cantidad de recursos, soy un fanático de todas las herramientas que ayudan a los desarrolladores "a solucionarlo". lo más pronto posible. Por esta razón, soy un defensor de cosas como IntelliSense que es tanto un aumento de la eficiencia como una herramienta que lo ayuda a implementar el código de trabajo más temprano en el ciclo. (Funciona, pero no  necesariamente  correcto.) 

 Por esta razón, también apoyo el uso de Option Strict como una forma de ayudar a mantener los pasos en falso y las correcciones consiguientes en el "tiempo de diseño". 
	


	
		
	
	
			 Si está acostumbrado a que se verifiquen sus tipos, entonces probablemente desee una opción estricta. apagarlo puede tener ventajas, pero si su cerebro no está sintonizado para detectar errores donde su compilador generalmente se queja, entonces yo diría que lo deje encendido. He trabajado mucho en VB.Net, y tengo que decir que, aunque trabajo con opciones estrictamente desactivadas la mayor parte del tiempo, he visto muchas situaciones en las que tenerlo activado habría evitado bastantes errores.



	
		
			Licenciado bajo: CC-BY-SA con atribución
			No afiliado a StackOverflow