Débat VB.Net vs C # [clos]

J'ai été dans des lieux de travail où, au début d'un projet, la question "Devrions-nous utiliser VB.Net ou C #" a été posée.

Certes, il est probablement moins courant d'avoir à prendre cette décision maintenant qu'elle ne l'était au début de .Net, en particulier compte tenu de la tendance à la convergence linguistique, mais cela peut encore être un débat houleux.

Donc, entre VB.Net et C #, quelle langue préférez-vous et pourquoi?

Je préfère C # à VB.NET car

• il est plus facile de trouver des programmeurs / emplois:

• il est plus facile de trouver de l'aide:

^{(à partir de stackoverflow)}

Je déteste VB.NET. Les jours que je passe encore à l'utiliser sont les jours que je regrette. Cela dit, mes goûts font partie de ma situation et de mon expérience, et n'ont pas nécessairement de rapport avec ce que vous faites ...

Je pense qu'il est important, lorsque l'on compare des langages en constante évolution comme C # et VB.NET, de revenir sur leur histoire et de voir comment ils sont arrivés à leur état actuel:

Les avantages originaux de BASIC sur les micro-ordinateurs comprenaient la taille et la simplicité (petite syntaxe facile à analyser conçue pour les petits interprètes assez rapides et laissé de la place en mémoire pour le programme et les données réels), un environnement interactif qui a permis l'expérimentation et une syntaxe qui évitait les symboles et les structures laconiques pour une syntaxe assez claire et semblable à l'anglais. Cependant, il n'était pas adapté aux grands programmes structurés et tendait à encourager le code de spaghetti. Pourtant, sa disponibilité et sa simplicité en ont fait un excellent choix pour une introduction à la programmation.

QuickBasic a mis à jour la syntaxe pour permettre de grands programmes plus structurés et ajouté la compilation pour une exécution plus rapide.

VisualBasic a fourni un générateur de formulaire puissant et facile à utiliser pour permettre la construction rapide d'applications GUI, tout en adoptant la syntaxe QB pour une utilisation dans l'écriture de scripts de ces interfaces utilisateur. Il fonctionnait mieux lorsqu'il était utilisé pour créer des interfaces utilisateur pour une logique de bas niveau fournie en tant que composants prédéfinis (généralement écrits dans un autre langage). Au fil du temps, la syntaxe est devenue de plus en plus volumineuse et incohérente à mesure que de nouvelles fonctionnalités étaient ajoutées. L'accent mis sur l'élaboration d'une interface utilisateur en premier, puis sur le remplissage de bits de script a bien fonctionné pour les petites applications centrées sur l'interface utilisateur, mais tendait à encourager la programmation par copier-coller et une variation du code spaghetti tout en décourageant la réutilisation, les structures de données complexes et séparation des préoccupations. Dans l'esprit de beaucoup, le "code VB" est devenu synonyme de "grosse boule de boue"; "Programmeur VB" avec "hack inexpérimenté".

VB.NET est un langage de type VB sur la plate-forme .NET, une tentative (pas entièrement réussie) de nettoyer et de moderniser la syntaxe VB envahie. Il n'était pas parfaitement compatible avec le code VB existant et n'a fait aucun effort pour assurer la compatibilité avec les formulaires VB (sans doute la partie la plus importante de VB). Cela a laissé de nombreux propriétaires de produits VB avec le choix désagréable de réécrire efficacement leurs applications dans VB.NET (traitant des incompatibilités subtiles dans chaque routine qui n'a pas été soigneusement examinée) ou de réécrire réellement leurs applications en C # (traitant d'un inconnu syntaxe en plus dela nouvelle bibliothèque d'exécution et le concepteur de formulaires). La plupart des utilisateurs de VB.NET étaient des utilisateurs de VB qui s'en sont tenus à la seule syntaxe, beaucoup l'utilisant comme béquille tout en apprenant le C #. En conséquence, il a immédiatement acquis une réputation de paradis pour les programmeurs qui étaient coincés dans leurs habitudes, ne voulant pas ou incapables d'étendre ou d'améliorer leurs compétences.

À ce stade, VB.NET continue d'évoluer, perdant lentement des bagages tout en récupérant une syntaxe nouvelle et intéressante (LINQ, littéraux XML). Pourtant, il ne conserve presque aucun des avantages originaux de BASIC: il s'agit d'un grand langage complexe avec une courbe d'apprentissage assez abrupte et des possibilités limitées d'expérimentation interactive.

• Pour les anciens programmeurs qui s'en sont tenus au cours des 30 dernières années, ce n'est pas un mauvais choix, à condition qu'ils ne s'y limitent pas.
• Pour les nouveaux programmeurs, la ressemblance de plus en plus vague des programmes VB avec l'anglais ne vaut guère les signes étranges de rétrocompatibilité et de stigmatisation sociale.
• Pour les nouveaux projets , VB.NET est un choix étrange à moins que le projet ne soit fortement impliqué dans l'une des rares tâches pour lesquelles le langage est optimisé: intégration avec des composants COM mal typés (Office ...) (bien que C # 4.0 réduit considérablement cet avantage ) ou la génération XML en ligne.

Je connais les deux, mais j'ai fait beaucoup de mes premiers travaux de programmation en VB4, VB5 et VB6. Maintenant que les deux langues en .NET ont traversé quelques itérations et ont convergé un peu dans leurs capacités, je pense que le débat est carrément idiot, un peu comme "quelle est votre couleur préférée."

Personnellement, je les aime tous les deux pour des raisons différentes.

VB.NET
Beaucoup de gens parlent de la façon dont la syntaxe C # est plus intuitive, mais c'est très subjectif et basé en grande partie sur ce que vous avez commencé à savoir. Je dirais que si vous étiez complètement objectif, la syntaxe VB.NET est probablement plus intuitive si vous ne supposez pas de connaissances préalables dans une autre langue. Par exemple, étant donné le même programme en C # et VB.NET qui, selon vous, serait plus déchiffrable pour quelqu'un qui n'a aucune connaissance de la programmation. Cela me semble assez clair.

L'autre chose intéressante à propos de cette syntaxe, c'est qu'elle est beaucoup plus explicite sur la fermeture des structures (END IF, END WHILE, NEXT X) par rapport au modèle de bracketing. Cela rend le code un peu plus lisible et permet souvent au compilateur d'être plus précis dans le numéro de ligne qui provoque exactement les erreurs de compilation. Si vous êtes déjà parti à la recherche d'un crochet / point-virgule manquant à cause d'une erreur de compilation à 50 lignes du problème, vous savez ce que je veux dire.

De plus, dans la colonne VB.NET win, à mon avis, il n'y a pas == / = d'opérateurs de comparaison / d'affectation. Les rares avantages d'avoir un opérateur distinct pour chacun ne compenseront jamais toutes les faiblesses (parfois) difficiles à découvrir qu'elle contribue à créer.

Enfin, je déteste la sensibilité à la casse dans les langages de programmation. L'une des plaintes à propos de VB est qu'il a tellement de bagages, mais C # a poursuivi l'albatros de la sensibilité à la casse de C. Je n'ai jamais été dans une situation où je voulais que deux identifiants de même portée ne diffèrent que par cas. Cela fait juste un travail occupé et me ralentit. VB.NET obtient pour moi quelques points sur C # à cet égard.

Les
programmeurs C # aiment être concis, c'est pourquoi je pense qu'ils préfèrent généralement cette syntaxe. Il a juste un certain attrait esthétique. Cependant, d'un point de vue complètement pratique, je l'aime parce qu'il est tellement similaire à des langages comme Java, JavaScript et C ++.

Étant donné que je fais beaucoup de développement Web qui nécessite une programmation côté serveur et côté client, je trouve plus facile de basculer mentalement entre C # et JavaScript, comme je suis souvent obligé de le faire.

J'aime aussi le fait que, pour la plupart, si jamais je devais passer à la programmation Java ou C ++, j'aurais un peu d'avance si j'utilisais C # la plupart du temps.

Je préfère la syntaxe des crochets des langages de style C à la syntaxe plus "verbeuse" des langages de style BASIC.

Mon introduction à la programmation a été avec Turbo Pascal. (Le peu de programmation BASIC que j'ai fait sur le Commodore 64, enfant, ne compte pas vraiment.) Après avoir appris Java, je n'ai jamais regardé en arrière et j'ai préféré la syntaxe de style C.

Ils sont fonctionnellement les mêmes, il n'y a rien que vous puissiez faire dans l'un que vous ne puissiez pas faire dans l'autre, et pour l'avenir, Microsoft s'est engagé à ce que les équipes linguistiques se développent de manière uniforme, de sorte que l'équivalence ne changera probablement pas.

Les différences sont désormais purement culturelles et personnelles. Cet article est une lecture intéressante sur les différences entre les cultures des programmeurs utilisant C # et VB.net

_{[Remarque: Bien que je sois moi-même un développeur C #, la conclusion de l'article lié ne reflète pas nécessairement mon opinion personnelle, c'est juste une approche alternative intéressante dans le débat]}

Je suis arrivé à .NET à partir de C et C ++ (avec un peu de Java, Ada et Pascal ajoutés), donc C # était la progression naturelle pour moi.

Si un travail arrivait qui nécessitait VB.NET, je ne le refuserais certainement pas.

J'ai fait beaucoup de travail avec VB.NET, mais je comprends suffisamment C # pour obtenir l'essentiel de ce qui se passe dans le code. Ma préférence actuelle est VB.NET parce que je la connais le mieux (évidemment), mais je n'ai pas vraiment de préférence entre la syntaxe BASIC verbeuse et la syntaxe de style C, les deux sont très lisibles et compréhensibles pour moi.

La plupart des connaissances en programmation de mon collègue sont COBOL et VB6, donc VB.NET était le choix de langage .NET le plus confortable pour nous en tant qu'équipe. Il n'y avait pas de raison solide pour nous qui ait rendu l'apprentissage du C # obligatoire car ils sont fonctionnellement les mêmes.

Cela dit, l'apprentissage du C # est sans aucun doute sur ma liste de choses à faire.

Je préfère C #.

J'ai commencé en tant que programmeur VB.NET mais avec le temps, il est devenu évident que beaucoup de nouvelles fonctionnalités arrivent d'abord en C #, puis en VB.NET (par exemple, la propriété automatique). Et la communauté autour de C # est beaucoup plus vivante que celle de VB.NET.

De plus, si vous avez l'intention d'apprendre Java ou un langage similaire, C # est un meilleur point de départ - la syntaxe est presque la même dans tous les langages dérivés de C. Bien que ce ne soit pas un point de basculement pour moi, car la syntaxe est quelque chose que vous pouvez apprendre rapidement de toute façon.

En plus des autres réponses publiées ici, je choisirais C # plutôt que VB car les programmeurs C # sont mieux payés. Plus d'expérience avec C # = plus $$ :)

Je sais que les deux langues sont presque les mêmes et c'est vraiment facile de basculer entre les deux, mais je pense que lorsque la direction examine un tas d'accolades et de points-virgules, elle accepte le fait que nous faisons quelque chose qu'elle ne peut pas faire, où avec VB. Net ils pourraient le regarder et dire "oh ça ne doit pas être si difficile à faire si je peux le comprendre"

C # parce que je peux basculer entre celui-ci et Java avec un minimum d'effort

VB.NET est une syntaxe entièrement différente. C #, étant similaire à Java et à d'autres langages, me donne une meilleure position pour m'adapter rapidement à de nouvelles choses. Étant donné que les sorties de C # et VB.NET sont pratiquement interchangeables, il est logique d'aller avec C #. De plus, si le code de votre entreprise est en C #, vous êtes plus susceptible d'être en mesure de former un développeur Java à coder C # qu'un développeur Java VB. Il n'y a que des avantages subtils, mais subtil est toujours un avantage.

Mettre mes préférences personnelles de côté. En tant que quelqu'un qui recrute (et essaie d'être recruté) récemment, lorsque nous avons eu ce débat au bureau, le consensus général était que nous devrions chercher à passer en C # de VB.

Pourquoi? Parce que C # était plus répandu sur le marché (autour de nous de toute façon), ce qui nous permettait de recruter plus facilement et d'être recruté plus facilement.

Il semble que la boucle soit bouclée; les gens apprennent le C # parce que les recruteurs le veulent, car il y a plus de candidats.

Étant un développeur un peu plus âgé (59 "un peu" plus âgé?), J'ai d'abord appris le BASIC sur un Commodore VIC-20, j'ai appris moi-même le Turbo Pascal (v1!), J'ai ensuite appris le COBOL à l'université et j'ai passé 14 ans à développer sur IBM mainframes, avec de brèves déviations écrivant des applications de taille moyenne dans Revelation BASIC (une variante de PICK BASIC) et quelques utilitaires dans Modula-2, avant de passer à côté de VB5 et VB6. Et puis est venu .NET.

En raison de mon expérience de base, j'ai pensé que je devrais commencer avec VB.NET, seulement pour découvrir que je continuais d'essayer de faire les choses "à l'ancienne" et que cela me rendait fou (d'accord, plus de noix). Étant donné que j'avais fait du travail en C, je pensais que je donnerais un tourbillon à C # pour voir comment cela se passait. Et OMG, c'était comme sortir d'un tunnel sombre en plein jour! Totalement inattendu. Et j'avais l'habitude de faire des bruits désobligeants sur le fait que C soit un langage "en écriture seule" - "si difficile à comprendre qu'un programmeur C ne pouvait pas comprendre ce que son propre code a fait 6 mois après l'avoir écrit", une observation faite par romancier semi-célèbre que je trouvais mignon à l'époque.

Donc, en raison d'être un peu peu familier avec C, C # était paradoxalement plus facile pour moi d'apprendre la programmation .NET que le paradigme de base beaucoup plus familier. J'aime toujours le VB6, mais j'aime le C #. Le meilleur langage de programmation de la planète.

Je développe en Visual Basic .Net depuis 2001 et je l'adore et je le déteste !!!

L'ordre de présentation de ces points est simplement basé sur l'ordre dans lequel il m'est venu à l'esprit ...

Dans vb.net avec visual studio, il y a un saut de ligne visuel entre chaque méthode, propriété. Pour beaucoup de gens, ce n'est pas une bonne raison de préférer vb.net à c # mais je ne comprends pas pourquoi l'équipe c # de Microsoft ne l'a pas implémenté. Il existe un complément qui dessine cette ligne en c # mais merci encore à Microsoft d'avoir une équipe ac # et une équipe Visual Basic qui ne se parlent pas.

Dans vb.net, lorsque vous créez un winform, vous avez deux combobox dans visual studio en haut de l'éditeur et vous pouvez générer automatiquement un événement automatiquement lorsque vous sélectionnez un événement dans la combobox droite. Lorsque vous attachez des dizaines d'événements chaque jour, il peut être très fastidieux de ne pas disposer de cette fonctionnalité. Avec c #, vous avez un petit bouton en haut de la grille de propriétés qui peut générer un événement mais ce n'est pas rapide comme dans vb.net. De plus, si vous attachez un événement de contrôle en c # et supprimez le contrôle sur le formulaire, le délégué créé sur le code généré automatiquement pour gérer l'événement doit être supprimé manuellement. Merci encore Microsoft.

Dans vb.net, lorsque vous essayez de modifier une méthode qui contient une requête linq sans modifier la requête elle-même, aucun problème mais en c #, tout le code de la méthode est verrouillé. Si vous avez beaucoup de requêtes linq ou d'expression lambda, la fonction d'édition et de poursuite sera rapidement une bonne vieille chose. D'accord, un peu d'exagération ... mais :)

Dans vb.net, lorsque vous créez un nom de méthode et appuyez sur Entrée, le 'end sub' sera automatiquement créé. En c #, faites-le vous-même. Ok, si vous avez installé resharper ou devexpress, ce sera mieux, mais pourquoi toutes ces petites mais grandes fonctionnalités n'ont pas été implémentées en c #.

Dans vb.net, lorsque vous avez des erreurs sur votre code, les erreurs sont automatiquement affichées et lorsque vous les corrigez, ces erreurs sont supprimées de la pile en temps réel. En c #, vous devez construire votre projet pour réaliser que vous avez correctement corrigé ou non les erreurs spécifiées. Pourquoi l'équipe c # n'a pas mis d'option pour vérifier les erreurs en temps réel comme dans vb.net. Avec une grande solution, aucune vérification d'erreur en temps réel ne peut être une très belle optimisation des performances mais j'aime voir une pile d'erreur disparaître pendant que je la corrige.

Comme d'autres personnes l'ont mentionné, je pense qu'il est plus facile de lire la condition de vb.net if..end if, select case ... end select mais avec le support de peinture devexpress, oubliez ce que j'ai dit.

Avec vb.net, il existe de nombreux bogues dans Visual Studio. Pour n'en citer qu'un dans Visual Studio 2010, les intellisens ne filtrent pas correctement l'énumération si vous avez activé le mode "commun" au lieu de "tous".

Avec vb.net, vous êtes perçu comme un mannequin parce que statiquement, plus de mauvais programmeurs utilisent vb.net au lieu de c # car c # est plus difficile à apprendre et à promouvoir de meilleures pratiques de programmation.

Comme d'autres l'ont dit, le programmeur c # a plus de chances d'avoir un bon travail avec plus d'argent.

Dans la tête du client, vb.net = gars qui programme dans son sous-sol avec un bol de spaghetti de code. c # = wow, vous êtes très intelligent. Le fait est que ce n'est pas parce que vous programmez en c #, que vous faites un bon programme mais statiquement, oui.

Avec tous ces points, j'ai choisi de convertir tout mon code vb en c #. Je programme avec toutes les meilleures pratiques orientées objet, design pattern, code propre avec standards et syntaxe stricte et je peux programmer comme ça depuis 50 ans mais aux yeux de la communauté, je ne suis pas un bon programmeur. Je vais convertir mon code en c # sans autres bonnes pratiques et je serai une autre personne; un grand gars que vous devez respecter ..... :( quelle blague ... !!! mais c'est la réalité.

Voici une façon de voir les choses: entre SO et CodePlex, quelle langue est la plus populaire? C # ou VB.Net?

Parfois, suivre le troupeau est une bonne chose car c'est le troupeau qui pourra vous aider quand vous en aurez besoin. Par défaut, C # sera plus rapide que Vb.Net. Je pense que l'utilisation d'Option Strict pourrait l'égaliser cependant. La dernière fois que j'ai comparé IL entre les deux, la sécurité de type de VB.Net a fini par ajouter environ 15% de plus à l'IL. Cela se traduit par des frais généraux supplémentaires. ET ... étant donné les langues qui font essentiellement la même chose, je prendrai la plus rapide. Ma commodité ne devrait pas l'emporter sur l'expérience de mon utilisateur en général.

J'aime dire que la seule raison pour laquelle BASIC est toujours populaire, c'est qu'il s'agissait du premier produit de Microsoft, et ils nous le mettent à la gorge depuis 35 ans. Il aurait dû mourir il y a longtemps.

Cela dit, j'ai travaillé sur deux projets .NET de grande taille et les deux ont été réalisés avec VB.Net - bien qu'il y ait un peu de C # car soit la traduction était une chienne, soit la construction n'existait pas dans VB.Net. Le seul avantage que je vois avec VB.Net est que l'éditeur Visual Studio est beaucoup plus convivial (selon mon expérience en tout cas) qu'avec C # - Intellisense semble meilleur, tout comme la mise en forme automatique (notez que puisque je n'ai pas utilisé C # autant, je manque peut-être quelque chose dans la configuration de l'IDE ...)

Un inconvénient majeur dans VB.Net est qu'ils ont apporté beaucoup de conneries de l'ère VB6 dans .NET 1.x pour faciliter la conversion du code VB6. Ce truc est toujours là, et les codeurs VB6 codent du nouveau code en utilisant ces ... "extensions" plutôt qu'en utilisant les classes / méthodes / NET plus neutres. Je ne sais pas combien de fois j'ai demandé à mon patron pourquoi il utilisait toujours cette merde. "Mais ... ça marche ..." Hé, j'aime salope.

En cherchant de l'aide sur le Web, j'ai trouvé que la grande majorité des solutions étaient en C # - consultez les forums MSDN, divers blogs, etc ... Les livres ont tendance à se concentrer sur C #, et s'il existe une version VB, elle vient généralement quelques mois plus tard (par exemple Pro LINQ .... d'Apress.)

De nombreux langages partagent l'ascendance C, ce qui rend la commutation entre C, C ++, C #, Java, PHP et quelques autres beaucoup plus facile. PHP est un peu extensible ici, mais il a beaucoup de constructions de type C. VB? Eh bien, c'est à peu près sa propre petite chose et c'est tout.

Un chef de projet dans mon organisation m'a récemment dit que de plus en plus de nouveaux projets sont développés en utilisant C # au lieu de VB - ENFIN. Lorsque .NET a été introduit dans notre organisation, ils ont plus ou moins officiellement opté pour VB.Net en raison de tout le codage VB6 qui était déjà en cours. Les pouvoirs qui m'ont été reconnus plus tard que ce n'était pas leur meilleure décision.

Comme quelqu'un d'autre l'a souligné ci-dessus, je ne dirais pas non à un projet VB.Net, mais j'espère toujours qu'il sera lentement éliminé des nouveaux développements sur mon lieu de travail.

Eh bien, aujourd'hui, il n'y a pratiquement aucune raison d'utiliser VB.net. Au début, c'était juste un moyen de donner aux programmeurs VB une syntaxe familière, mais c'était essentiellement un remappage BASIC de type C #. Son seul véritable avantage est donc une syntaxe plus familière, et sa syntaxe BASIC est également sa seule limite réelle.

Au fil du temps, les deux langues ont évolué parallèlement, la seule différence significative est le my pseudo-espace de noms.

Je conseillerais à chaque programmeur .net qui n'est pas familier avec C # de l'apprendre, car la communauté est assez grande et la syntaxe de type C est commune à la plupart des langages les plus utilisés.

VB la langue est plus facile à lire pour les débutants, ils ont tendance à y écrire leur première, deuxième et troisième application et nous savons tous à quoi ressemblent nos premières applications - terriblement.

Les programmeurs de C ++, Java et etc. sont passés à C # tandis que les développeurs VB.NET viennent de fond VBA, VB et BASIC, des programmeurs non traditionnels essentiels.

Il semble y avoir plus d'exemples de code C # en ligne que d'exemples VB.NET. Pas comme si difficile de convertir l'un en l'autre, mais pourquoi s'embêter si vous n'avez pas à le faire.

Je préfère VB .Net à C #,

• (97) ...
• (98) parce que j'ai appris le VB avant même de connaître C #.
• (99) parce que j'ai déjà acheté un tome de 10 000 pages sur VB .Net.
• (100) car VB n'a pas d'accolades.
• (101) parce que tout le monde déteste VB.

C #. C'est juste parce que j'ai fait C et Java, donc je pense que C # est plus lisible pour moi. C # est pour moi, comme VB.NET pour les anciens programmeurs VB.