Alors, je ne veux pas que cela soit dans une guerre de flamme entre les développeurs C # et VB.NET. Cela est purement du point de vue d'un département de développement à l'avenir. Nous avons été une société VB.NET pendant des années, mais c'était principalement due à qui nous avons embauché. Cette exigence est tombée de la voie à la fin, car nous avons tiré dans 2 gars qui se spécialisent dans C #. J'étais un gars C ++ / C # avant de convertir VB.NET pour cette entreprise.
Ainsi, à tous ceux qui doivent faire face à cela, que ce soit sur une base de localisation ou une base de maintenabilité: comment gérez-vous la normalisation des langues de choix d'aller de l'avant? Je suis enclin à faire une poussée pour C #, car cela fera 3 développeurs C # solides ici. Mais juste curieux de ce que les pensées de chacun sont.
12 Réponses :
Sur une base purement des capacités, ils sont aussi proches que deux langues peuvent obtenir. VB.Net a tendance à obtenir plus d'interactivité COM et de XML littéral - mais C # en reçoit une partie de cela bientôt.
Ce n'est vraiment que la préférence personnelle et quelle langue vous pensez que l'équipe peut être la plus productive.
Il y a quelques années, nous nous sommes normalisés sur C # parce que c # semble avoir plus d'un suivi parmi les développeurs sérieux.
Permettez-moi d'être clair Je ne dis rien de mal à propos de vb.net ou de ceux qui l'utilisent.
Sur un client précédent, qui avait écrit leurs applications critiques de mission dans VB, ils ont commencé à trouver plus difficile de trouver des programmeurs VB par opposition à c #.
Ils ont donc décidé de commencer à changer leurs applications sur C #.
Comme avec la plupart des questions IT / DEV, la réponse est-elle dépend. Si vous avez plus de personnes dans votre département qui sont superbes avec VB, passez avec VB. Je ne pense pas que l'un des est beaucoup mieux que l'autre.
Exactement. Tout cela compile jusqu'au CLR en utilisant les mêmes bibliothèques exactes. La langue elle-même dans .NET n'est que du sucre syntaxique.
Si vous avez beaucoup de code déjà écrit dans une langue particulière, préférez cette langue.
Sinon, si vous avez plus de développeurs bien versé dans une langue de l'autre, préférez cette langue.
Sinon, préférez C # (il est généralement plus populaire et fonctionné, ils ne sont pas suffisamment différents pour faire un choix significatif sur les fonctionnalités seules).
Il semble que le meilleur plan d'action pour nous était de passer à une boutique C #. Je suis à l'origine un C ++ Dev par échange, de sorte que, associé à un groupe de développeurs en cours d'embauche, les gars C # et le marché des gars C # ont fait un choix facile. Cela fonctionne également en réalité parce que nous avons une bibliothèque de code que nous réorganisons pour s'adapter aux normes de l'API. Il faut donc la passer à C # devrait être une bonne pratique.
qui dépend entièrement du pool de développeurs que vous avez.
La question que vous demandez est réellement très importante et trop de gens vous diront que le choix de la langue n'est que la préférence personnelle. Mais vous savez déjà que, du point de vue d'une organisation, ce n'est pas vrai. Choisir un ensemble standard de cadres, de langues, d'outils, etc. est une décision commerciale importante.
Vos programmeurs devraient pouvoir utiliser une langue avec un peu de temps, encouragement et peut-être un peu de formation. C # et VB sont proches et il n'y a pas de raisons techniques significatives de choisir un sur l'autre ...
Donc, mon conseil est de choisir la langue de votre organisation en fonction des raisons des entreprises. Si vous embauchez des gars C # est plus facile, ou si vous trouvez qu'ils ont tendance à avoir de meilleures compétences pour le type de travail que vous faites, alors marquez un pour C #. Si vous écrivez du code pour les clients et que ces clients préfèrent les livrables C #, obtenez un autre sur un autre pour C #. Si vous avez du code existant dans VB, marquez-en un pour VB.
Ce devrait être une panne assez simple ... Ignorer simplement les raisons techniques et concentrez-vous sur la manière dont le choix de la langue affectera votre entreprise en termes d'embauche, de formation, de capacité à fournir au client, etc.
On dirait que vous avez déjà une norme - VB.NET. Et peut-être que vous êtes tenté ou intéressé à entrer dans C # à la place.
Il est très difficile d'avoir la moitié de vos systèmes rédigés dans VB et à moitié écrit en C # - bien que, en fonction de la nature de votre organisation, cela peut ne pas s'appliquer. Mais généralement, l'organisation ne devrait pas prendre ces changements légèrement.
Si j'étais vous (et que vous êtes intéressé de passer à C # pour vous-même), j'appuie que c #, mais si j'étais l'affaire, j'aurais besoin d'une très bonne raison d'introduire cette nouvelle complexité, de la question des coûts et de la gestion .
S'il y a une seule raison d'adopter C # pour votre entreprise, il s'agit de l'opérateur Lambda. Sans le soutien total de l'opérateur de Lambda dans VB.NET, certains des meilleurs outils deviennent soit criplés, soit des DOA. Par exemple: Nibernate fluide, StructureMap, etc.
Comme quelqu'un qui travaille dans un magasin mixte, ce n'est pas si difficile à obtenir en utilisant les deux. Mais il est utile d'avoir une norme qui facilite la déplacement de code. Voici quelques idées pour votre standard:
pour les développeurs VB:
convert.to ___ () fonction dans la mesure du possible pour une conversion facile vers et depuis C #.
- Exiger
option strict et option explicite . Vous abandonnerez une bonne fraîcheur dynamique en faisant une exigence comme une suggestion forte, mais cela vaut la peine de garder la parité de code avec C #.
- standardisez sur '+' vs '&' pour la concaténation de chaîne (si vous n'utilisez pas déjà un StringBuilder)
- Préférez
andalso et orelse sur et et ou
pour les développeurs C #:
- interdire les noms qui ne diffèrent que par le cas. Cela inclut notamment des noms qui sont fondamentalement les mêmes que le nom de type (
pr quelque type = ... ). Dites-leur d'utiliser un préfixe _ à la place (et non "m_"). Vous devriez le faire quand même mais c'est particulièrement important dans un magasin mixte car ce code sera plus difficile à travailler avec VB.
pour les deux:
- interdire des arraylistes et d'autres collections non génériques (car non seulement ils sont diaboliques de toute façon, mais VB et C # manipulent la coulée de toutes requis très différemment, même avec des options strictes grâce à CTYPE)
Si vous le faites, il y aura peu de différences réelles entre le code des deux groupes, et vous avez pris la première étape pour enseigner aux développeurs de VB à penser comme des développeurs C #.
Très bons points. Je travaille dans un magasin de VB uniquement, mais nous suivons toujours toutes vos normes, à savoir que ces principes aboutissent à un code plus robuste et sûr de toute sécurité conforme aux normes-cadres.
Même le '+' vs '&'? La plupart des magasins VB-Seuls que j'ai entendus envisageraient de considérer celui-là en arrière.
Joel, puis-je obtenir votre raisonnement sur le _ vs. m_? Nous avons eu des discussions internes à ce sujet et ont déterminé que c'est une question de goût. De plus, il y avait des références vagues à _ étant réservées en quelque sorte, alors nous avons fini par aller avec m_.
C'est surtout goût: le m_ a l'air vraiment étrange dans le code VB. En outre, ce modèle d'utilisation n'est pas toujours membre; Parfois, c'est un local.
@Joel Coehoorn: Non, vous avez raison, nous utilisons et. Je pensais que vous vouliez vouloir normaliser sur l'un ou l'autre.
Et je préfère cela de cette façon, en fait, mais si vous utilisez à la fois C # et VB, il est certainement moins déroutant d'utiliser +!
@Joel: Je vois - c'est juste pour les noms de variables identiques que les noms de type et diffèrent par le cas. Nous avons résolu que, parce que presque tous nos noms de classe sont des entités ou des collections d'entités, nous utilisons la notation hongroise avec E et C respectivement, et que dans ce cas. En règle générale, nous n'utilisons pas HN, mais dans ce cas, cela fonctionne bien.
Veuillez ne pas utiliser de préfixe _ pour les locaux, ce serait terriblement déroutant (il est largement utilisé spécifiquement sur mettre en surbrillance les champs!). Je ne sais pas quelle est la pratique de la VB standard pour les habitants, mais personnellement, j'ai toujours aimé la façon dont SmallTalk le fait, en préfixant avec A ou un ou le , selon la plupart des sens; I.e.: Acustomer en tant que client, anorder comme ordre ".
Avoir de bonnes raisons d'aller avec une norme sur une autre devrait être le facteur de guidage. Utilisez ceci:
1. La verbosité ne provoque pas de problème de productivité car l'IDE fait une bonne partie du travail pour vous. Par exemple, si vous tapez "si quelque chose" puis appuyez sur Entrée, puis terminez si elle est ajoutée automatiquement.
2. vb.net a des expressions Lambda ?? 3. VB.NET est similaire à VB6. VB Syntaxe est facile à ramasser de toute façon ... 4. Des tableaux déchiquetés? Vous avez besoin de ça pour quoi ??
Oups. Je n'ai pas réalisé que vb.net pourrait faire des expressions Lambda maintenant. Mais je suis ennuyé de devoir taper "Dim" et "comme" chaque fois que je veux initialiser une variable. Et aussi loin que la syntaxe VB étant simple, comment testez-vous pour des inégalités référentielles? "N'est pas" ou "n'est pas"? Que diriez-vous de type casting? Préféreriez-vous faire "(int) x" ou "CTYPE (x, int)"? Et je pense que c'est hilarant que quelqu'un pense que VB6 et VB.NET sont similaires. En dehors de là étant "sombre" s et "comme" s, les langues sont radicalement différentes au point où il y a pratiquement zéro transfert de connaissances d'une langue à l'autre.
En outre, le fait que j'ai besoin d'un IDE pour générer les constructions verbeuses de la langue ne me ticent plus. Je ne veux pas que mon code n'apparaisse plus plus que nécessaire. Je pense que c'est implicite que je veux "faire quelque chose" après avoir écrit une déclaration IF, de sorte que je n'ai pas besoin de spécifier "alors". Et FYI, les matrices déchiquetées sont une structure de données extrêmement répandue et je pense que c'est un fait assez connu et accepté. Découvrez le wiki: en.wikipedia.org/wiki/ragged_array#applications_2
Si vous codez votre application dans le Bloc-notes, alors oui, la verbosité de VB.Net devient rapidement ennuyeuse. Avec Visual Studio, IntelliSense et Resharbeur (si vous l'avez), la verbosité de la langue est une non-question en ce qui me concerne. FYI, je suis un développeur C #.
Je voulais dire que VB6 et VB.NET ont une syntaxe similaire, tout comme C # et C ++ ont une syntaxe similaire, mais rien d'autre en commun ;-) Quant aux matrices de Jagged, mon point était que dans de nombreux scénarios (comme le mien), vous n'avez pas besoin de eux du tout. Il peut être difficile d'initialiser un dans VB, mais si vous choisissez une langue basée sur cela, quelque chose ne va pas avec vos facteurs de décision: p
Nous avons récemment eu le même problème. Nous ne faisons que coder dans les deux, en fonction de ce que le projet d'origine a été lancé. Il est étonnamment facile de passer d'avant en arrière, en particulier avec Visual Studio (cela me "rappelle toujours" quand je commence à taper "Bool Myvar ..." que je Je fais quelque chose de mal si je suis dans un fichier .vb).
Notre priorité va comme ceci:
Quelle est la taille de votre magasin? Si c'est 3 sur 6, cela se spécialise dans C #, il serait relativement facile de basculer. Si c'est 3 heures 30, ce serait plus difficile d'entrer en C #.