Ac # dev devrait-il passer à VB.net lorsque la base linguistique de l'équipe est mixte?

J'ai récemment rejoint une nouvelle équipe de développement où les préférences linguistiques sont mélangées sur la plate-forme .net.

• Dev 1: Connaît VB.net, ne sait pas c #

• Dev 2: Connaît VB.net, ne sait pas c #

• Dev 3: Connaît c # et VB.net, préfère c #

• Dev 4: Connaît c # et VB6 (VB.net devrait être assez facile à comprendre), préfère c #

Il me semble que les leaders d'opinion dans l'espace .net sont des développeurs c # presque universellement. Je pensais également que certains outils tiers ne prenaient pas en charge VB.net, mais lorsque j'ai commencé à l'examiner, je n'ai trouvé aucun bon exemple.

Je préférerais que toute l'équipe soit en c # mais s'il n'y a aucune bonne raison de forcer le problème en dehors de la préférence, je ne pense pas que ce soit le bon choix.

Y a-t-il des raisons pour lesquelles je devrais éloigner les gens de VB.net?

Il n'y a aucune raison vraiment contraignante de forcer quelqu'un à changer de langue, à moins qu'une fonctionnalité ne soit particulièrement utile ou ne fasse gagner du temps à vos projets. Ils compileront tous les deux en IL et fonctionneront de manière équivalente (en supposant que cela Option Strictsoit activé dans VB.NET ... sinon vous pouvez encourir des pénalités pour une liaison tardive). Tout le reste est vraiment préférentiel (ne pas le rejeter du tout, mais ce n'est pas une métrique objective).

Je suggérerais de consulter les listes d'emplois dans votre région et de voir quelle langue est la plus répandue dans l'offre de travail (c'est-à-dire le bassin de main-d'œuvre pour les deux langues). Voir lequel vous fournira un bassin de main-d'œuvre plus grand ou meilleur sera probablement votre mesure la plus convaincante.

Heureusement, la réponse est simple: il n'y a pas de "meilleure" langue. Tous les langages .NET utilisent, à leur racine, les fonctionnalités de l'ensemble de classes fournies par le .NET Framework. Par conséquent, tout ce que vous pouvez faire dans VB.NET, vous pouvez le faire en C # et vice-versa. Les seules différences entre les langues ne sont que syntaxiques.

Les programmeurs C ++, Java et J ++ préféreront la syntaxe concise et non-sens de C #. Les programmeurs Visual Basic (VB) peuvent préférer s'en tenir au diable qu'ils connaissent - l'approche du langage pseudo-naturel insensible à la casse de Visual Basic .NET. Si vous avez des programmeurs VB et que ce sont de vrais programmeurs (voir Option Strict ON), vous obtiendrez les mêmes résultats. VB est plus verbeux .... C # est un jeu de balle avec sensibilité à la casse.

Honnêtement, une équipe de développeurs devrait utiliser la même langue ou, à tout le moins, connaître les mêmes langues.

Cela facilitera la formation croisée et le support entre diverses applications produites par une équipe de développement.

En fin de compte, VB vs C # est une bataille de préférences, mais l'équipe devrait être sur la même page que celle qu'elle va utiliser ou soutenir.

Ac # dev devrait-il passer à VB.net lorsque la base linguistique de l'équipe est mixte?

Le développeur doit utiliser le langage .NET qui est la norme pour l'équipe. OMI, il devrait y avoir une langue qui est utilisée (à moins qu'un cas extrêmement convaincant puisse être présenté).

Y a-t-il des raisons pour lesquelles je devrais éloigner les gens de VB.net?

Je pense que la plupart des gens ici préfèrent C # mais ce n'est pas tant une question technique qu'une décision politique ou commerciale. Décidez quel langage .NET utiliser, puis utilisez-le. Maintenant, il y a évidemment un tas de facteurs à considérer:

• Existe-t-il une base de code existante? Dans quelle langue la majorité est-elle écrite?
• Les développeurs VB.NET peuvent-ils facilement récupérer C #? Le veulent-ils?
• Est-il financièrement judicieux d'investir dans la montée en puissance / formation C #?
• Quel serait l'impact d'un changement de langue sur les livrables existants?

En fait, VB.NET possède quelques fonctionnalités que C # ne possède pas actuellement: les littéraux XML et la syntaxe de requête pour utiliser la méthode Aggregate dans LINQ.

Vous pouvez consulter ces trois articles qui comparent C # et VB.NET:

• Comparaison de C Sharp et Visual Basic .NET
• Choisir entre C # et VB.NET
• Comparaison VB.NET et C #

Ils semblent tous fournir des arguments et des comparaisons très logiques entre les deux. Personnellement, je vote pour C # (mon entreprise a choisi C # pour nos projets ASP.NET lorsque nous sommes passés de l'asp classique).

J'étais dans une situation très similaire en 2003 dans laquelle vous vous trouvez actuellement. Je dirigeais une équipe qui passait à ASP.NET depuis ASP Classic. La plupart de notre équipe avait de l'expérience avec VBScript comme langage de facto pour ASP, mais environ la moitié de l'équipe était en faveur de C # malgré un chemin de migration légèrement plus complexe depuis ASP / VBScript. En fin de compte, j'ai choisi VB.NET, mais rétrospectivement, je souhaite vraiment avoir choisi la voie C #.

Le 5e anniversaire de cette décision, j'ai écrit un article de blog sur ma justification pour prendre la décision et j'ai essayé de fournir le bénéfice de mon recul aux autres responsables du développement qui tentaient de faire le même appel. Voici un lien vers l'article:

"Rétrospective d'un manager sur la décision C # versus VB.NET"

Pour faire court, pour ceux qui ne veulent pas lire l'intégralité de l'article: je ne pense pas que le projet était pire pour avoir choisi VB.NET plutôt que C #, et cela nous a probablement fait gagner beaucoup de temps à court terme. Le plus gros problème était vraiment le recrutement. Je serais heureux d'embaucher un programmeur C # ou VB.NET pour travailler dans les deux langues. Ils ne sont vraiment pas si différents. Cependant, qu'il soit mérité ou non, VB.NET a une stigmatisation qui fait qu'un bon nombre de développeurs évitent les emplois où ils savent qu'ils travailleront avec lui comme langue principale.

Je pencherais pour C # parce qu'il est moins verbeux et d'après mon expérience, il est beaucoup plus répandu sur Internet. Je dirais également que C # ou VB.NET sont faciles et rapides à apprendre, au point où ils sont négligeables et insignifiants. Le framework .NET, en revanche, est énorme et une créature en constante évolution. La maîtrise de .NET prend plusieurs années, mais la maîtrise de C # ou VB.NET peut prendre quelques mois ou moins.

Je pense que @Anna Karin a un bon point, vous ne devriez donc pas avoir à vous soucier des bibliothèques. Au moins, je ne me souviens de personne qui fonctionne avec c # et non avec vb.net.

Un autre point important est qu'il rendra les vérifications de code plus difficiles entre les membres de la même équipe s'ils travaillent avec des langues différentes. Je pense que c'est une meilleure idée d'utiliser un langage commun, pour réduire les frictions dans la communication.

Bien que je sois d'accord avec la réponse précédente selon laquelle .NET devrait avoir la même fonctionnalité, ce n'est pas toujours le cas, mais suffisamment proche pour que si vous avez un projet simple, cela ne devrait pas avoir d'importance.

La principale raison que je donnerais pour passer au C # dans toute l'équipe est que c'est le langage dans lequel la plupart des exemples sont et la plupart des projets open source publient du code source en C #. Donc, si votre équipe n'est pas en mesure d'intégrer une telle ressource, vous vous limitez peut-être inutilement.

C # et VB.NET sont basés sur la plate-forme .NET; il est important pour les développeurs qui travaillent en .NET de connaître .NET, les principes, les techniques, les modèles ... Dans ce cas, le changement de langue ne sera pas un problème - il s'agit principalement de syntaxe. Dans une équipe mixte, tous devraient peut-être essayer d'apprendre les deux langues (ce n'est pas grave), mais cela peut être important pour la future collaboration entre les membres de l'équipe.

Je dirais que le seul avantage d'avoir tout le monde utilisant le même langage est que cela signifierait que tout développeur pourrait travailler sur n'importe quelle partie du code.

Au-delà de cela, VB.NET et C # ne diffèrent que par la syntaxe sous .NET. Et le code écrit dans les deux langues peut très bien coexister dans le même projet.

J'irais avec C # parce que:

• il est plus proche de Java et C ++ (langages très souvent enseignés dans les cours CS).
• il y a beaucoup de ressources sur Internet en C # qu'en VB (d'après ce que j'ai vu là-bas).
• les chances sont plus grandes de trouver / embaucher d'autres développeurs qui connaissent mieux C # que VB (d'après ce que j'ai vu dans mon entreprise) pour maintenir le projet.

Mon avis serait de permettre le développement basé sur un contrat avec une interface, et le développeur devrait être capable de coder une classe dans la langue qu'il souhaite, et probablement de séparer les classes de bas / haut niveau dans différents assemblys. Tant que les classes respectent l'interface demandée et implémentent l'exigence, il devrait y avoir peu de problèmes.

Je suis d'accord avec de nombreuses autres réponses ici. J'ai fait partie de deux équipes qui ont dû prendre cette décision. Dans les deux cas, ils ont d'abord décidé que les développeurs pouvaient choisir car les deux langues fonctionnent ensemble. Cependant, au cours de la première année, ils souhaitaient tous deux avoir choisi C # et imposer une nouvelle exigence que tous les nouveaux projets soient en C #.

Raisons d'utiliser C #:

• Cela a fait plaisir à deux de vos développeurs jusqu'à présent, et pourrait bien englober les deux autres une fois qu'ils l'ont appris.
• Vous prévoyez d'embaucher plus de développeurs à un moment donné et vous voulez éviter la foule des "20 ans d'expérience VB".
• Vous aimez les accolades frisées.
• Tu aimes la vie.

Raisons d'utiliser VB.NET:

• Les deux développeurs qui ne connaissent pas C # refusent absolument de l'apprendre.
• "Déambuler sur le chemin de la moindre résistance" est la devise de votre entreprise.
• Il existe une énorme base de code VB existante qui ne peut pas être mise à jour.
• Vous êtes sur un coup de pied HP Lovecraft, et déplorez le manque d '"horreurs eldritch" dans votre vie de tous les jours.