Je n'ai vu personne commenter votre deuxième question explicite à la fin: "2: est-ce suffisamment convaincant pour que j'envisage de passer à C # si le cas de VB.NET limite en quelque sorte ce que je pourrais faire avec du code?"
Je préfère l'approche plus d'options que C # laisse le programmeur choisir de limiter les options du programmeur. Je préfère fortement C #, mais pour la seule sensibilité à la casse, je ne le penserais même pas proche d'apprendre un langage simplement parce qu'il est sensible à la casse. toutes les fonctionnalités sont ce qui compte, et quand je regarde les avantages des deux, C # et VB.NET, je préfère fortement C #. mais je vais vous donner une vraie perspective équilibrée, biaisée oui, car j'ai une préférence, mais je serai honnête sur les inconvénients de C # aussi.
tout d'abord, les deux langues présentent des avantages et des inconvénients. les différences que vous pouvez faire dans une langue qui ne peuvent pas être faites dans l'autre diminue car, heureusement, Microsoft améliore les deux langues, et ils ne semblent pas montrer de partialité injuste envers l'une ou l'autre langue.
lorsque C # est sorti pour la première fois, VB n'avait pas ses commentaires XML que vous pouviez mettre avant les méthodes, ce que j'ai adoré en C #. je détestais ça dans VB.NET. mais j'ai vu au fil des ans, que de nombreuses fonctionnalités qui ne sont pas dans une langue s'ajoutent à l'autre. (la même équipe de développeurs MS développe à la fois C # et VB, il est donc logique que les fonctionnalités deviennent assez similaires.)
mais vous avez demandé ce que C # a que VB n'a pas. en voici quelques-uns auxquels je peux penser immédiatement:
1: C # est plus concis et prend moins de frappe .. de plusieurs façons! J'ai même vu la stupidité parler quand la prétention opposée est faite, que VB sauve la frappe. mais écoutez les personnes qui vous disent qu'elles utilisent les deux langues et qu'elles ne l'utilisent que rarement. j'utilise à la fois C # etVB, C # à la maison parce que je l'aime (et quand je travaille avec C # au travail), et mes demandes d'emploi plus récentes que j'utilise VB et non C #. Je reçois donc une utilisation plus fréquente de VB maintenant (depuis environ 10 mois maintenant), mais dans mon témoignage personnel, je préfère de loin C #, et en termes de frappe réelle, VB est considérablement plus typée. le seul exemple que j'ai lu où quelqu'un a en fait essayé de dire que VB était plus concis, donnait un exemple «avec ...» avec une longue variable dans le avec, donc en VB, vous pourriez simplement utiliser «.property». il est stupide de prétendre que VB a besoin de moins de frappe. il y a quelques choses (et pas seulement cet exemple) où VB est plus court, mais beaucoup plus de fois où C # est plus concis, dans la pratique réelle.
mais la principale raison pour laquelle je pense que C # est plus concis, ce sont les déclarations verbeuses "IF / THEN" de VB. si les déclarations sont courantes. en C # il n'y a pas de mot «alors» à taper! :) aussi toutes les instructions 'end ...' prennent un typage qui en c #, n'est généralement qu'une accolade fermante '}'. J'ai lu que certaines personnes prétendent que cette plus grande verbosité dans VB.NET est un avantage pour VB car plusieurs instructions / symboles de bloc de fermeture peuvent être imbriqués et se terminer immédiatement les uns à côté des autres, mais je ne suis pas du tout d'accord. une personne peut presque toujours écrire un programme mieux en C # ou en VB qu'un autre programmeur car la prochaine révision de code pourrait être mieux conçue. cela s'applique à la «confusion de nombreuses accolades fermantes en C #» plus si les blocs imbriqués sont tous du même type que plusieurs IF imbriquées, alors VB souffre du même problème qu'en C #. ce n'est pas un avantage en VB. cette situation est précisément la raison pour laquelle j'aime commenter ce que mon symbole de clôture ou mon énoncé de clôture va de pair dans les deux langues. oui, c'est plus détaillé à faire, mais dans l'une ou l'autre langue, vous avez la possibilité d'être clair, ce qui est important dans les cas spécifiques basés sur le jugement et la situation. Je pense que la clarté du code est assez importante.
2: VB n'a pas de commentaires sur plusieurs lignes. quand je travaillais avec VB, cela ne me dérangeait pas. puis je suis allé à quelques langages de style C. maintenant, je suis de retour principalement en utilisant VB.NET au travail, et ils me manquent. c'est juste quelque chose que vous trouvez pratique et que vous devez ensuite perdre. :(
3: 'andalso' et 'orelse' de VB est assez ennuyeux de taper tout cela quand en C # c'est simplement '&&' et '||'. encore une fois, moins de frappe. ce n'est pas rare dans mon code en VB et C #. si quelque chose, pour la fonctionnalité, 'OR' vs 'OrElse' n'a généralement pas d'importance sauf que 'OrElse' est plus rapide pour l'ordinateur, donc si un programmeur utilise simplement 'Or' et 'Et' dans VB, alors il produit un code moins optimal pour quelqu'un qui aime la clarté du code. «Ou» est beaucoup plus facile à parcourir que «OrElse».
4: plus de flexibilité dans le placement du code en C #. quand une ligne est longue et que vous voulez l'envelopper sur la ligne suivante, je déteste le réajustement de contrôle de mon code par VB.NET. C # le fait un peu, mais je le trouve plus utile en C #, où en VB, c'est beaucoup plus contrôlant. mais il s'agit davantage de l'IDE VB.NET vs IDE C # plutôt que du langage lui-même. mais je ne sais pas si vous voulez les deux ou uniquement les fonctionnalités linguistiques sans différences IDE.
5: celui qui me manque vraiment est simplement de créer un nouveau bloc de code en C #, il se peut que beaucoup de choses se passent dans une méthode et je veux déclarer une variable dans un très petit bloc de code mais ne pas déclarer cette variable en dehors de ce bloc dans toute la méthode. en C #, nous pouvons simplement créer un nouveau bloc avec '{' et le terminer par '}'. VB n'a pas une telle fonctionnalité, mais sa correspondance la plus proche est un bloc inconditionnel «If True Then» et «End If». (notez à nouveau l'équivalent de 2 caractères C # vs 18 caractères VB.NET ... plus de saisie en VB.)
6: opérateurs d'auto-incrémentation et de décrémentation: ++ et - comme dans myVariable++ou ++myVariableou les versions de décrémentation équivalentes. cela est très pratique ... parfois. voici un exemple de code réel lorsque j'ai beaucoup manqué C #:
// C#:
while (txt.Length > x)
{
thisChar = txt[x];
if (charsAllowedWithoutLimit.Contains(thisChar)) { ++x; }
else if (allowLettersWithoutLimit && char.IsLetter(thisChar)) { ++x; }
else if ((x2 = charsAllowedWithLimit.IndexOf(thisChar)) >= 0)
{
++x; if (++usedCountA[x2] > charAllowedLimit[x2]) { break; }
}
else { break; }
}
' VB.NET:
While (txt.Length > x)
thisChar = txt(x)
If (charsAllowedWithoutLimit.Contains(thisChar)) Then
x += 1
ElseIf (allowLettersWithoutLimit AndAlso Char.IsLetter(thisChar)) Then
x += 1
Else
x2 = charsAllowedWithLimit.IndexOf(thisChar)
If (x2 >= 0) Then
x += 1
usedCountA(x2) += 1S
If usedCountA(x2) > charAllowedLimit(x2) Then Exit While
Else
Exit While
End If
End If
End While
Et juste pour donner un TRES bon exemple de règles C #, c'est plus de code que j'ai personnellement écrit récemment:
// C#
public static bool IsNotWithin(this Byte v, Byte v1, Byte v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this SByte v, SByte v1, SByte v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this Int16 v, Int16 v1, Int16 v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this Int32 v, Int32 v1, Int32 v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this Int64 v, Int64 v1, Int64 v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this UInt16 v, UInt16 v1, UInt16 v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this UInt32 v, UInt32 v1, UInt32 v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this UInt64 v, UInt64 v1, UInt64 v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this Decimal v, Decimal v1, Decimal v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsWithin(this Byte v, Byte v1, Byte v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this SByte v, SByte v1, SByte v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this Int16 v, Int16 v1, Int16 v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this Int32 v, Int32 v1, Int32 v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this Int64 v, Int64 v1, Int64 v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this UInt16 v, UInt16 v1, UInt16 v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this UInt32 v, UInt32 v1, UInt32 v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this UInt64 v, UInt64 v1, UInt64 v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this Decimal v, Decimal v1, Decimal v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
' And the VB equivalent is a mess! Here goes:
<Extension()>
Public Function IsNotWithin(v As Byte, value1 As Byte, value2 As Byte) As Boolean
Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function
<Extension()>
Public Function IsNotWithin(v As SByte, value1 As SByte, value2 As SByte) As Boolean
Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function
<Extension()>
Public Function IsNotWithin(v As Int16, value1 As Int16, value2 As Int16) As Boolean
Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function
' the % suffix means 'As Integer' in VB.
<Extension()>
Public Function IsNotWithin(v%, value1%, value2%) As Boolean
Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function
' the & suffix means 'As Long' in VB.
<Extension()>
Public Function IsNotWithin(v&, value1&, value2&) As Boolean
Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function
<Extension()>
Public Function IsNotWithin(v As UInt16, value1 As UInt16, value2 As UInt16) As Boolean
Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function
<Extension()>
Public Function IsNotWithin(v As UInt32, value1 As UInt32, value2 As UInt32) As Boolean
Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function
<Extension()>
Public Function IsNotWithin(v As UInt64, value1 As UInt64, value2 As UInt64) As Boolean
Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function
' the @ suffix means 'As Decimal' in VB.
<Extension()>
Public Function IsNotWithin(v@, value1@, value2@) As Boolean
Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function
<Extension()>
Public Function IsWithin(v As Byte, value1 As Byte, value2 As Byte) As Boolean
Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function
<Extension()>
Public Function IsWithin(v As SByte, value1 As SByte, value2 As SByte) As Boolean
Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function
<Extension()>
Public Function IsWithin(v As Int16, value1 As Int16, value2 As Int16) As Boolean
Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function
' the % suffix means 'As Integer' in VB.
<Extension()>
Public Function IsWithin(v%, value1%, value2%) As Boolean
Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function
' the & suffix means 'As Long' in VB.
<Extension()>
Public Function IsWithin(v&, value1&, value2&) As Boolean
Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function
<Extension()>
Public Function IsWithin(v As UInt16, value1 As UInt16, value2 As UInt16) As Boolean
Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function
<Extension()>
Public Function IsWithin(v As UInt32, value1 As UInt32, value2 As UInt32) As Boolean
Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function
<Extension()>
Public Function IsWithin(v As UInt64, value1 As UInt64, value2 As UInt64) As Boolean
Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function
' the @ suffix means 'As Decimal' in VB.
<Extension()>
Public Function IsWithin(v@, value1@, value2@) As Boolean
Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function
C'est peut-être une preuve suffisante que C # est plus concis. Mais tous les programmeurs n'aiment pas la concision. Certains préfèrent lire "si a <b alors ..." parce que c'est plus naturel pour leur langage humain. Et c'est très bien. Les préférences sont bien. Pour moi, l'effort de la main est une valeur du facteur i, et je pense que n'importe qui peut s'habituer à penser dans les symboles qu'il préfère, car "si" et "alors" sont des symboles d'un alphabet et "si (condition) instruction;" de C #; la syntaxe sont aussi des symboles. l'un est juste plus proche de la syntaxe d'un non-programmeur que l'autre. je préfère le concis.
Je pense aussi que le besoin d'utiliser «c» après les littéraux de caractères dans VB pour en faire un littéral de caractère plutôt qu'une chaîne est ennuyeux. J'aime bien plus la concision de C #. lorsqu'une méthode nécessite un caractère littéral, vous devez fournir un caractère et non une chaîne avec une longueur de caractère, donc parfois vous êtes obligé de l'utiliser ":"cen VB alors qu'en C # c'est le cas ':'. Je pense que c'est un peu difficile.
Pour être juste, je dirais qu'il ya des avantages que j'aime VB comme ne pas avoir à mettre entre parenthèses vides après les appels de méthode, comme Dim nameUpper$ = name.ToUpperInvariantoù C # exige que les parenthèses vides: string nameUpper = name.ToUpperInvariant(). soit le double que , comme la coupe trop: Dim nameUpper$ = name.Trim.ToUpperInvariantvs string nameUpper = name.Trim().ToUpperInvariant(). J'aime l'utilisation concise par VB de la façon dont je viens de l'utiliser$ ci-dessus pour le réduire `` As String '' où C # n'a pas ces raccourcis. VB a ces raccourcis pour les types String, Integer, Long, Decimal, Single et Double, mais l'inconvénient est qu'il est moins clair, donc je l'utilise avec prudence. mais néanmoins, je préfère un code concis.
Eh bien, ce ne sont que quelques thots de ce programmeur chevronné, et comme je le considère, c'est mon `` témoignage '' de programmation de C # vs VB. les deux sont de belles langues tho, à mon avis. mais oui, je préfère toujours beaucoup C #.
ps Puisque je prévois de programmer la majeure partie de ma vie, j'ai même réappris à taper en utilisant le clavier le plus efficace: le clavier Dvorak, qui demande environ 1/3 d'effort pour taper l'anglais que sur un clavier Qwerty. Cherchez-le. peut-être que vous voudrez peut-être changer aussi. ;) cela a rendu ma frappe 67% plus facile! :) J'encourage tout le monde à sortir des sentiers battus et à évaluer une meilleure efficacité dans votre travail. La disposition de clavier simplifiée Dvorak et C # l'ont fait pour moi. :)
PSS i comparerait le Dvorak et C # à la métrique par opposition à la disposition du clavier Qwerty et VB aux mesures Empirial. Dvorak, métrique et C # sont simplement «propres». MAIS VB n'est pas vraiment loin derrière. Mais il souffre de la nécessité d'être rétrocompatible avec l'ancien code VB6 et le code pré .NET, comme le 'Or' vs 'OrElse' et 'IIF ()'.
Je termine avec une prudence. Soyez plus prudent que d'écouter des gens qui ne savent pas vraiment de quoi ils parlent. La moitié de tous les inconvénients contre VB et C # sont ne pasaucun problème, et les gens continuent de signaler qu'ils ignorent les inconvénients qui existent encore dans la langue. Le meilleur exemple auquel je puisse penser est celui des commentaires XML pour les méthodes utilisant une triple apostrophe en VB ou des symboles de commentaire triple barre oblique en C #. Mais s'il vous plaît, discernez par vous-même si une personne parle par ignorance ou par expérience. Le témoignage personnel signifie qu'ils savent de leur expérience réelle. Et une fois que quelqu'un a beaucoup d'expérience dans ce domaine, réveillez vos oreilles. J'ai plus de 10 ans d'expérience en C # et VB. Et cela se résume à ceci: les deux sont de (très) bonnes langues. Et la plupart des différences, vous pouvez voir immédiatement dans les 5 minutes suivant la lecture du code. Mais oui, d'autres fonctionnalités peuvent mettre des années à trouver un handicap. Et un handicap dont je suis conscient (en C #), je peux ' t même penser à une situation réelle où cela serait utile. Ce n'est donc peut-être pas un handicap après tout.
Bon codage!