¿Debería ac # dev cambiar a VB.net cuando la base de idiomas del equipo es mixta?


14

Recientemente me uní a un nuevo equipo de desarrollo donde las preferencias de idioma se mezclan en la plataforma .net.

  • Dev 1: sabe VB.net, no sabe c #

  • Dev 2: sabe VB.net, no sabe c #

  • Dev 3: conoce c # y VB.net, prefiere c #

  • Dev 4: conoce c # y VB6 (VB.net debería ser bastante fácil de aprender), prefiere c #

Me parece que los líderes de pensamiento en el espacio .net son c # devs casi universalmente. También pensé que algunas herramientas de terceros no eran compatibles con VB.net, pero cuando comencé a buscarlo, no encontré ningún buen ejemplo.

Preferiría poner a todo el equipo en c #, pero si no hay una buena razón para forzar el problema aparte de la preferencia, entonces no creo que sea la opción correcta.

¿Hay alguna razón por la que deba alejar a la gente de VB.net?


55
La verbosidad dentro de VB solo debería llevarte a C # ...
Aaron McIver

13
Me parece que su equipo de desarrollo carece de un liderazgo serio. ¿Por qué su gerente no se ha ocupado de este problema?

2
¿Por qué te desplazas hacia VB .Net? De su diagrama anterior, los 2 desarrolladores con alguna habilidad conocen C # y los demás no conocen ningún .Net. ¿Seguramente sería mejor poner al día a aquellos que no conocen ninguno de los idiomas con C # ya que los otros dos desarrolladores ya tienen habilidades en C # para desarrollar?

15
Debajo del capó pueden ser lo mismo, pero la sintaxis de VB es la fea hermana infestada de verrugas parada junto a su hermana C # más caliente y bien bañada. Su sintaxis debe recordarse solo como un punto de referencia para la sangre que se ha derramado de los ojos de muchos desarrolladores al contemplar su propia versión del infierno. VB debe ser castrado, asesinado y dejado a un lado de la carretera para que se pudra en el cálido calor del verano. Abraza la sintaxis más bella y evita lo que la madre naturaleza ha decidido olvidar. Elegir sabiamente.
Moo-Juice

2
Si no me equivoco, On Error Resume Next es para soporte heredado. Intente Los bloques Catch existen en VB.Net ... ya que es .Net.
Tony Abrams

Respuestas:


2

No hay una razón realmente convincente para obligar a alguien a cambiar los idiomas a menos que uno tenga una característica que sea particularmente útil o que ahorre tiempo para su (s) proyecto (s). Ambos compilarán a IL y funcionarán de manera equivalente (suponiendo que Option Strictesté activado en VB.NET ... de lo contrario, puede incurrir en penalizaciones por enlace tardío). Todo lo demás es realmente preferencial (no descartarlo en absoluto, pero no es una métrica objetiva).

Sugeriría mirar los listados de trabajo en su área y ver qué idioma es más frecuente tanto en la oferta de trabajo (es decir, el grupo de trabajo para ambos idiomas). Ver cuál le proporcionará un grupo de trabajo más grande o mejor probablemente sea su métrica más convincente.


Estoy de acuerdo con lo que dijiste sobre los listados de trabajo locales. Creo que una cosa que es fácil de pasar por alto es el potencial grupo de talentos, y el efecto de elegir un idioma sobre el otro puede tener en sus futuros esfuerzos de contratación.
jjr2527

7

Afortunadamente, la respuesta es simple: no existe el "mejor" lenguaje. Todos los lenguajes .NET usan, en su raíz, la funcionalidad del conjunto de clases proporcionadas por .NET Framework. Por lo tanto, todo lo que puede hacer en VB.NET lo puede hacer en C #, y viceversa. Las únicas diferencias entre los idiomas son meramente sintácticas.

Los programadores de C ++, Java y J ++ preferirán la sintaxis concisa y sin sentido de C #. Los programadores de Visual Basic (VB) pueden preferir quedarse con el demonio que conocen: el enfoque de lenguaje pseudonatural que distingue entre mayúsculas y minúsculas de Visual Basic .NET. Si tiene programadores de VB y ellos son programadores reales (ver Opción estrictamente activada) obtendrá los mismos resultados. VB es más detallado ... C # es un rompe bolas con mayúsculas y minúsculas.


Es cierto, ambos pueden hacer un 98% que el otro puede PERO hay tanta cuerda para ahorcarse en VB. On Error Resume Nextsolo me enviaría corriendo hacia C #. El Moduleconcepto también es muy peligroso. Es similar a un static classen C # pero ... todo en él es accesible globalmente sin referencia a la clase padre y automáticamente estático sin ninguna otra indicación ... ¡excepto que la clase padre es un Módulo ...!
Paul Sasik

66
Lo siento, pero esto no es cierto. Por ejemplo, ¿cómo escribiría un filtro de excepción en C #? blogs.msdn.com/b/clrteam/archive/2009/08/25/…

@LukeH Para agregar un filtro de excepción a C #, podemos construir una función en VB o IL, luego llamarla en C #: D

44
@Anna: refutando así su afirmación de que "todo lo que puede hacer en VB.NET lo puede hacer en C #" .

2
Hay bastantes cosas que simplemente no puede hacer en VB.Net que puede hacer en c # - vea también: stackoverflow.com/q/2362381/50447
Rowland Shaw

5

Honestamente, un equipo de desarrolladores debe estar usando el mismo idioma o al menos saber los mismos idiomas.

Esto ayudará en el entrenamiento cruzado y el soporte entre varias aplicaciones que produce un equipo de desarrollo.

Al final, VB vs C # es toda una batalla de preferencias, pero el equipo debe estar en la misma página en cuanto a cuál van a usar o apoyar.


5

¿Debería ac # dev cambiar a VB.net cuando la base de idiomas del equipo es mixta?

El desarrollador debe usar el lenguaje .NET que es el estándar para el equipo. En mi opinión, debe usarse un idioma (a menos que se pueda presentar un caso extremadamente convincente).

¿Hay alguna razón por la que deba alejar a la gente de VB.net?

Creo que la mayoría de las personas aquí prefieren C #, pero esto no es tanto una cuestión técnica como una decisión política o comercial. Decide qué lenguaje .NET usar y luego úsalo. Ahora, obviamente, hay un montón de factores a considerar:

  • ¿Existe una base de código existente? ¿En qué idioma está escrita la mayoría?
  • ¿Pueden los desarrolladores de VB.NET elegir fácilmente C #? ¿Quieren ellos?
  • ¿Tiene sentido financieramente invertir en la intensificación / capacitación de C #?
  • ¿Cómo impactaría cualquier cambio de idioma en los resultados existentes?

+1 por pensar en el equipo, en lugar de las preferencias individuales
MarkJ

4

De hecho, VB.NET tiene algunas características que C # no tiene actualmente: literales XML y sintaxis de consulta para usar el método Agregado en LINQ.


1
VB.NET tampoco tiene iteradores (es decir, palabra clave Yield en C #).
atconway


2

Estaba en una situación muy similar en 2003 en la que te encuentras ahora. Estaba administrando un equipo que se estaba mudando a ASP.NET desde ASP Classic. La mayoría de nuestro equipo tenía experiencia con VBScript como el lenguaje de facto para ASP, pero aproximadamente la mitad del equipo estaba a favor de C # a pesar de una ruta de migración un poco más compleja desde ASP / VBScript. Finalmente, elegí VB.NET, pero en retrospectiva, realmente desearía haber seguido la ruta C #.

En el quinto aniversario de esa decisión, escribí un artículo de blog sobre mi justificación para tomar la decisión y traté de proporcionar el beneficio de mi retrospectiva a otros gerentes de desarrollo que intentan hacer esa misma llamada. Aquí hay un enlace al artículo:

"Una retrospectiva del gerente sobre la decisión de C # versus VB.NET"

Para resumir, para aquellos que no quieren leer el artículo completo: no creo que el proyecto haya empeorado al elegir VB.NET sobre C #, y probablemente nos haya ahorrado mucho tiempo a corto plazo. El mayor problema fue realmente con el reclutamiento. Con mucho gusto contrataría a un programador de C # o VB.NET para trabajar en cualquier idioma. Realmente no son tan sustancialmente diferentes. Sin embargo, ya sea merecido o no, VB.NET tiene un estigma que hace que un buen número de desarrolladores eviten trabajos en los que saben que trabajarán con él como idioma principal.


Como programador de C #, he trabajado en proyectos que usan VB.NET. Pero la mayoría de las veces, los programadores de VB.NET no sabían lo que estaban haciendo, no tenían grados de Comp Sci y escribieron métodos con cientos de líneas de código. Por lo tanto, me incliné para ignorar cualquier anuncio de trabajo que pidiera VB.NET.
Ian

1

Me inclinaría hacia C # porque es menos detallado y, en mi experiencia, es mucho más frecuente en Internet. También diría que C # o VB.NET son fáciles y rápidos de aprender, hasta el punto de que es insignificante e insignificante. El marco .NET, por otro lado, es enorme y una criatura en constante evolución. Dominar .NET lleva muchos años, pero dominar C # o VB.NET puede llevar algunos meses o menos.


0

Creo que @Anna Karin tiene un buen punto, por lo que no debería preocuparse por las bibliotecas. Al menos, no recuerdo a nadie que solo funcione con c # y no con vb.net.

Otro punto importante es que hará que las comprobaciones de código sean más difíciles entre los miembros del mismo equipo si trabajan con diferentes idiomas. Creo que es una mejor idea usar un lenguaje común, para reducir la fricción en la comunicación.


0

Si bien estoy de acuerdo con la respuesta anterior de que .NET debería ser la misma característica, este no es siempre el caso, pero lo suficientemente cerca como para que si tienes un proyecto simple no sea importante.

La razón principal que daría por cambiar a C # en todo el equipo es que es el lenguaje en el que se encuentran la mayoría de los ejemplos y la mayoría de los proyectos de código abierto publican el código fuente en C #. Por lo tanto, si su equipo no puede obtener dicho recurso, puede estar limitándose innecesariamente.


0

C # y VB.NET se basan en la plataforma .NET; Es importante que los desarrolladores que trabajan en .NET conozcan .NET, principios, técnicas, patrones ... En ese caso, cambiar de idioma no será un problema, se trata principalmente de la sintaxis. En un equipo mixto, tal vez todos deberían tratar de aprender los dos idiomas (no es gran cosa), pero puede ser importante para la futura colaboración entre los miembros del equipo.


0

Yo diría que la única ventaja de que todos usen el mismo lenguaje es que significaría que cualquier desarrollador podría trabajar en cualquier parte del código.

Más allá de eso, VB.NET y C # difieren solo por sintaxis en .NET. Y el código escrito en ambos idiomas puede coexistir en el mismo proyecto perfectamente.


0

Yo iría con C # porque:

  • está más cerca de Java y C ++ (lenguajes que a menudo se enseñan en cursos de CS).
  • Hay muchos recursos en Internet en C # que en VB (por lo que he visto por ahí).
  • Es más probable encontrar / contratar a otros desarrolladores que conozcan C # mejor que VB (por lo que he visto en mi empresa) para mantener el proyecto.

0

Mi opinión sería que permitiría el desarrollo basado en contratos con interfaz, y el desarrollador debería poder codificar una clase en el idioma que desee, y probablemente separar las clases de bajo / alto nivel en diferentes ensamblajes. Mientras las clases respeten la interfaz solicitada e implementen el requisito, no debería haber ningún problema.


0

Estoy de acuerdo con muchas de las otras respuestas aquí. He sido parte de dos equipos que han tenido que tomar esta decisión. En ambos, inicialmente decidieron que los desarrolladores podían elegir, ya que los dos idiomas funcionan juntos. Sin embargo, durante el primer año en ambos desearon haber elegido C # y haber establecido un nuevo requisito de que todos los proyectos nuevos estén en C #.


0

Razones para usar C #:

  • Ha hecho felices a dos de sus desarrolladores hasta ahora, y bien puede engullir a los otros dos una vez que lo aprendan.
  • Planea contratar más desarrolladores en algún momento y desea evitar la multitud de "20 años de experiencia VB".
  • Te encantan las llaves.
  • Amas la vida

Razones para usar VB.NET:

  • Los dos desarrolladores que no conocen C # se niegan absolutamente a aprenderlo.
  • "Caminar por el camino de menor resistencia" es el lema de su empresa.
  • Existe una enorme base de código VB que no se puede actualizar.
  • Estás en una patada de HP Lovecraft y lamentas la falta de "horrores horrendos" en tu día a día.
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.