.net - similares - reemplazo de visual basic

Option Strict On y.NET para programadores de VB6 (8)

Estoy preparando una clase en 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 estilo C, principalmente Java y C #, así que para mí el casting explícito 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 integrado para la vinculación tardía , porque no tener que ser excesivamente explícito acerca de los tipos en el código realmente ahorra tiempo. Esto se prueba aún más con la difusión popular de los lenguajes de tipado dinámico , incluso en la plataforma .NET con Dynamic Language Runtime.

Con esto en mente, alguien que se acerque a .NET por primera vez con VB.NET y con un fondo de VB6, se le anima 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 está "bien" continuar disfrutando de los beneficios de la vinculación tardía?

¡¡¡¡SÍ!!!!

En mi opinión, tanto como desarrollador, y como instructor de la universidad SÍ.

Lo mejor es 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.

adicional

Hay literalmente toneladas de razones que podrían enumerarse en cuanto a 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.

Dada la noción de Boehm de que resolver un problema antes en el ciclo de desarrollo consume menos recursos, soy fanático de todas las herramientas que ayudan a los desarrolladores a "hacer las cosas bien" lo antes 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 al principio del ciclo. (Trabajando, pero no necesariamente correcto)

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

El tiempo invertido en desarrollar con Option Strict enable le ahorrará una gran cantidad de tiempo de depuración más adelante.

Recuerde que hay dos niveles aquí.

Opción Explicit Option Strict

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 entusiasta paritularily cuando se trata de objetos que han implementado o heredado diferentes interfaces y clases.

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

A lo largo de los años con VB, prácticamente uso Double para todas las variables de coma flotante. De esta forma evitará muchos problemas con el redondeo y la pérdida de precisión. En VB6 utilicé 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 alguna vez decida redefinir esas palabras clave.

Si está acostumbrado a que se revisen sus tipos, entonces probablemente desee una opción estricta. apagarlo puede tener ventajas, pero si tu cerebro no está atento a detectar errores de los que normalmente se queja tu compilador, te aconsejo que lo dejes. He trabajado mucho en VB.Net, y tengo que decir que, aunque trabajo con opciones estrictamente desactivadas la mayoría de las veces, he visto muchas situaciones en las que tenerlo encendido habría evitado bastantes loco.

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 están in favour de Option Strict en .NET. Muchos programadores experimentados de VB6 saben que la conversión automática es una "coacción de tipo perverso" ( pdf ), y estarán encantados de activar Option Strict .

Ocasionalmente, 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 demuestra la regla.

¡Sí! Option Strict es definitivamente una mejor práctica con .Net. Enfatice que .Net está en su núcleo una plataforma fuertemente tipada, y lo estará hasta que el DLR sea más completamente compatible. Con pocas excepciones, cada Dim y Function debería tener un tipo explícito declarado para ir con él. 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 eres muy consciente de todo esto, pero he tenido que trabajar y mantener un montón de código VB.Net escrito por antiguos VB6ers, por lo que este es un punto doloroso para mí:

No use 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 las Pautas de diseño de Microsoft si no le creen.
Asegúrese de que aprenden sobre los nuevos operadores lógicos AndAlso / OrElse
CONSULTAS PARÁMETRIZADAS y ADO.Net moderno. No puedo enfatizar eso lo suficiente. Nunca deberían necesitar volver a llamar a CreateObject() .
El alcance 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 orientado a objetos reales puede ser diferente, en comparación con el soporte de OOP parcial provisto por VB6. Ya no hay una buena razón para permitir que los métodos corran a longitudes impías.
Asegúrese de que reciban una introducción a Generics and Interfaces (incluyendo IEnumeralbe(Of T) ), y aprenda por qué nunca deberían usar una ArrayList nuevamente.

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

Option Strict obviamente no puede reemplazar las buenas pruebas unitarias, pero tampoco al revés. Si bien las pruebas unitarias pueden detectar los mismos errores que Option Strict , esto implica que no hay errores en las pruebas unitarias, que las pruebas unitarias se realizan a menudo y temprano, etc.

Escribir buenas pruebas unitarias no siempre es trivial y lleva tiempo. Sin embargo, el compilador ya implementa algunas de las pruebas, en forma de comprobación de tipos. Por lo menos, esto ahorra tiempo. Es más probable que esto ahorre mucho tiempo y dinero (al menos ocasionalmente) porque sus pruebas fueron erróneas / no cubrieron todos los casos / se olvidó de 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 gran garantía de que la verificación de tipos realizada por el compilador es correcta o al menos que sus fallas (covarianzas de matriz no revisadas, errores con referencias circulares ...) son bien conocidas y están bien documentadas.

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