¡Me desarrollo en Visual Basic .Net desde 2001 y me encanta y lo odio!
El orden de presentación de estos puntos se basa solo en el orden en que vino a mi mente ...
En vb.net con Visual Studio, hay un salto de línea visual entre cada método, propiedad. Para muchas personas, no es una buena razón para preferir vb.net sobre c #, pero no entiendo por qué el equipo de c # en Microsoft no lo ha implementado. Hay un complemento que dibuja esta línea en c # pero agradece nuevamente a Microsoft que tenga un equipo ac # y un equipo visual básico que no se comuniquen entre sí.
En vb.net, cuando crea una forma de triunfo, tiene dos cuadros combinados en Visual Studio en la parte superior del editor y puede generar eventos automáticamente al seleccionar un evento en el cuadro combinado correcto. Cuando adjuntas docenas de eventos cada día, puede ser muy engorroso no tener esta función. Con c #, tiene un pequeño botón en la parte superior de la cuadrícula de propiedades que puede generar eventos, pero no es tan rápido como en vb.net. Además, si adjunta un evento de control en c # y elimina el control en el formulario, el delegado creado en el código generado automáticamente para manejar el evento debe eliminarse manualmente. Gracias de nuevo Microsoft.
En vb.net, cuando intenta modificar un método que contiene una consulta linq sin modificar la consulta en sí, no hay problema, pero en c #, todo el código del método está bloqueado. Si tiene muchas consultas linq o expresiones lambda, la función de edición y continuación será rápidamente algo bueno. Ok, un poco de exageración ... pero :)
En vb.net, cuando crea un nombre de método y toca enter, se creará automáticamente el 'fin de sub'. En c #, hágalo usted mismo. Ok, si tiene resharper o devexpress instalado, será mejor, pero ¿por qué todas estas pequeñas pero excelentes características no se implementaron en c #?
En vb.net, cuando tiene errores en su código, los errores se muestran automáticamente y cuando lo corrige, estos errores se eliminan de la pila en tiempo real. En c #, debe crear su proyecto para darse cuenta de que ha corregido correctamente o no los errores especificados. ¿Por qué el equipo de C # no ha puesto una opción para verificar el error en tiempo real como en vb.net? Con una gran solución, ninguna verificación de error en tiempo real puede ser una optimización muy agradable del rendimiento, pero me encanta ver desaparecer un montón de errores mientras lo corrijo.
Como otra persona ha mencionado, creo que es más fácil leer la condición vb.net si ... termine si, seleccione el caso ... finalice la selección pero con el soporte de pintura devexpress, olvide lo que dije.
Con vb.net, hay muchos errores en Visual Studio. Solo por mencionar uno en Visual Studio 2010, los intellisens no filtran correctamente la enumeración si tiene el modo "común" activado en lugar de "todos".
Con vb.net, eres percibido como un tipo ficticio porque estáticamente, más programadores malos usan vb.net en lugar de c # porque c # es más difícil de aprender y promover una mejor práctica de programación.
Como dijo otro, el programador de C # tiene más posibilidades de tener un buen trabajo con más dinero.
En la cabeza del cliente, vb.net = chico que programa en su sótano con un bol de espagueti de código. c # = wow, eres muy inteligente. El hecho es que no es porque programes en c #, que haces un buen programa, sino estáticamente, sí.
Con todos estos puntos, elegí convertir todo mi código vb en c #. Programo con todas las mejores prácticas de orientación a objetos, patrón de diseño, código limpio con estándares y sintaxis estricta y puedo programar así durante 50 años, pero desde la perspectiva de la comunidad, no soy un buen programador. Convertiré mi código en c # sin otras prácticas recomendadas y seré otra persona; un gran tipo al que debes respetar ..... :( ¡qué broma ... !!! pero es la realidad.
