VB est-il vraiment insensible à la casse?

La différence entre VBA et VB.NET est juste parce que VB.NET comstack en permanence en arrière-plan. Vous obtiendrez une erreur lorsque vous comstackrez le VBA.

Comme le dit Jonathan , lors de la programmation, vous pouvez considérer VB.NET comme insensible à la casse, à l’exception des comparaisons de chaînes, du XML et de quelques autres situations …

Je pense que vous êtes intéressé par ce qu’il y a sous le capot. Eh bien, .NET Common Language Runtime est sensible à la casse et le code VB.NET repose sur le runtime, vous pouvez donc voir qu’il doit être sensible à la casse lors de l’exécution, par exemple lors de la recherche de variables et de méthodes.

Le compilateur et l’éditeur VB.NET vous permettent d’ignorer cela – car ils corrigent la casse dans votre code.

Si vous jouez avec des fonctionnalités dynamics ou une liaison tardive (Option Ssortingct Off), vous pouvez prouver que l’exécution sous-jacente est sensible à la casse. Une autre façon de voir cela est de réaliser que les langages sensibles à la casse tels que C # utilisent le même runtime, de sorte que le runtime supporte évidemment la sensibilité à la casse.

EDIT Si vous voulez sortir l’EDI de l’équation, vous pouvez toujours comstackr à partir de la ligne de commande . Modifiez votre code dans le Bloc-notes pour qu’il ss SS et SS et voyez ce que fait le compilateur.

EDIT Citation de Jeffrey Richter dans la page .NET Framework Design Guidelines 45.

Pour être clair, le CLR est en fait sensible à la casse. Certains langages de programmation, comme Visual Basic, sont insensibles à la casse. Lorsque le compilateur Visual Basic tente de résoudre un appel de méthode vers un type défini dans un langage sensible à la casse comme C #, le compilateur (pas le CLR) calcule le cas réel du nom de la méthode et l’intègre dans les métadonnées. Le CLR ne sait rien à ce sujet. Maintenant, si vous utilisez la reflection pour vous lier à une méthode, les API de reflection permettent d’effectuer des recherches insensibles à la casse. C’est la mesure dans laquelle le CLR offre une insensibilité à la casse.

Une partie du problème ici est que vous devez diviser la langue de l’expérience IDE.

En tant que langage, VB.NET est certainement insensible à la casse par rapport aux identificateurs. Appeler DateTime.Parse et datetime.parse se lieront exactement au même code. Et contrairement aux langages comme C #, il est impossible de définir des méthodes ou des types qui ne diffèrent que par cas.

En tant qu’EDI, VB.NET tente de conserver la casse des identifiants existants lorsqu’il répertorie un bloc de code. De jolies listes apparaissent chaque fois que vous quittez la ligne de code logique actuelle. Dans ce cas, vous quittez la deuxième déclaration de SS , le joli lister remarque qu’il existe un identifiant existant avec ce nom et le corrige pour avoir la casse correspondante.

Ce comportement, cependant, est purement effectué en tant que valeur ajoutée par l’utilisateur. Ce n’est pas une partie de la langue principale.

VB est principalement insensible à la casse, mais il existe des exceptions. Par exemple, les littéraux XML et la compréhension sont sensibles à la casse. Les comparaisons de chaînes sont généralement sensibles à la casse, contrairement à T-SQL, mais il existe des options de compilation pour rendre les comparaisons de chaînes insensibles à la casse. Et bien sûr, il y a les cas extrêmes concernant l’inheritance, COM et Dynamic Language Runtime.

Oui, le compilateur VB.NET traite les identificateurs de manière insensible à la casse. Et oui, cela peut causer des problèmes quand il consum des assemblys écrits dans un autre langage ou utilise des composants COM. Le premier cas est couvert par la spécification de langage commun . La règle pertinente est la suivante:

Pour que deux identificateurs soient considérés comme distincts, ils doivent différer plus que leur cas.

Le créateur de la bibliothèque de types s’occupe plutôt grossièrement du cas COM, il force le casse des identifiants du même nom à être identiques. Même lorsque ces identificateurs ont des rôles différents. En d’autres termes, un paramètre de méthode nommé “index” forcera le nom de la méthode “Index” à être indexé sur “index”. Cela a produit beaucoup de grattage, comme vous pouvez l’imaginer 🙂

VB préserve la casse (dans l’EDI) mais n’est pas sensible à la casse . C’est un peu comme le système de fichiers Windows. Hello.txt et hello.txt sont considérés comme étant le même nom de fichier.

L’EDI suppose que la déclaration d’une variable est la casse “correcte” pour cette variable et ajuste chaque instance de cette variable en fonction de la déclaration. Il le fait pour des raisons de clarté et de cohérence, mais pas pour la fonctionnalité.

J’ai vu plusieurs cas où le cas n’a pas été automatiquement modifié pour correspondre à la déclaration, et la déclaration fonctionne de la même manière. Vous pouvez également utiliser n’importe quel éditeur de texte pour écrire du code qui comstackra parfaitement dans différents cas.

Une note latérale:

La plupart des personnes pensent de manière insensible à la casse. Lorsque nous voyons le mot “chien”, le mot est traduit en sens dans nos esprits. La signification du mot ne repose pas sur un cas (c’est-à-dire qu’il épelle “DOG”, “DoG” ou “dOG”). ORDINATEURS voient les mots comme des sacs de bits discrets. Les majuscules et les minuscules sont des modèles de bits différents et sont donc différents.

Comme la plupart des programmeurs sont humains, l’insensibilité à la casse semble plus adaptée à la manière dont les gens pensent et la sensibilité à la casse concerne plutôt les humains qui adaptent leur façon de penser aux contraintes d’une machine.

Cela fait partie de l’éditeur que vous utilisez, ils peuvent se comporter différemment mais le fait est que Visual Basic est vraiment un langage insensible à la casse. Donc, SS et SS sont les mêmes.

S’il vous plaît jeter un oeil au tutoriel VB.NET Basics pour plus d’informations 🙂

Je ne suis pas sûr de te comprendre? VB est insensible à la casse, donc ss et SS sont la même variable, donc le compilateur se plaint correctement que vous avez déclaré à nouveau la variable.

Je pense que les variables ne sont pas sensibles à la casse, mais les noms de fonction sont.

Oui, VB est insensible à la casse. Parfois, il jette un peu de boucle à ceux qui ne sont pas habitués.

Il n’est pas nécessaire d’essayer tout cela avec VB.NET pour créer du code avec différentes «orthographes» majuscules / minuscules d’un identifiant. Changer le casse d’un identifiant dans le fichier où il est déclaré sans utiliser la fonction “Renommer” n’entraînera pas la mise à jour du nom dans les autres fichiers, cependant, éditer une ligne contenant le nom le rendra conforme à la définition actuelle.

De cette manière, on peut déterminer que VB.NET est essentiellement insensible à la casse, mais il met la casse des identificateurs à la disposition du CLR, qui peut utiliser cette information de manière sensible à la casse.

Je ne peux que proposer cela, ce dont je me souviens de mes manuels de programmation au début des années 80, est-ce que les langages sensibles étaient (à l’époque) ssortingctement destinés à réduire les erreurs de compilation. C’est-à-dire que la “rigueur” visait à développer une discipline de codage plus précise. Comme il s’est avéré que l’ajout d’un étiquetage correct des variables, des classes, des méthodes, des fonctions et de tout ce que vous souhaitez y inclure a également évolué.

Je me souviens que presque tous ces livres incluaient un modèle recommandé pour la capitalisation dirigée, les minuscules, etc. Comme nous le soaps tous, une grande partie a été rejetée ou devrait-elle être ignorée dans la pratique, sauf pour les maisons de production haut de gamme. Solutions CASE, ou pour ceux qui ont atteint un niveau de compétence supérieur. Je pense que tout le monde fait l’expérience de cette courbe d’apprentissage.

Compte tenu de l’avancement de ces langages et IDE, la meilleure question devient, quelle langue améliore mon temps de développement? Bien sûr, si vous n’êtes pas familier avec chacun des langages, vos options sont limitées.

Je vais essayer de répondre à votre deuxième question.

“Est-ce assez convaincant pour moi de penser à passer à C # si le cas VB.NET limite d’une manière ou d’une autre ce que je pourrais faire avec le code?”

Créez un service Web WCF en utilisant C #. Créez un contrat de données (1 classe). Un avec la propriété “ssortingng email”. Une autre avec “ssortingng Email” comme une autre propriété. Votre choix pour comprendre comme email personnel ou email de bureau. Ou il pourrait être dans deux différents DataContracts.

Pour C # c’est bien. Le service Web est créé correctement. Le programme AC # peut facilement créer un WSDL et tout va bien.

Maintenant, essayez de créer un WSDL avec VB (n’importe quelle version). Il dira “email” est déjà déclaré et la génération WSDL échoue.

Comme tout le monde, je pensais que c’était un inconvénient en langage VB. Mais!!!

Utilisez FxCOP et parsingz le code C # d’origine. FxCOP dit qu’utiliser email / email est un problème. Recommande d’utiliser un nom différent prenant en charge l’insensibilité à la casse. Notez également qu’à ce jour, le framework .NET dispose de 106 langages de programmation et que de nombreuses langues ont la sensibilité à la casse activée. Nous évoluons tous vers le cloud et souhaitons que nos services soient accessibles par toutes les plates-formes / langages de programmation.

Donc, être sensible à la casse est votre choix dans votre programme et si vous êtes un gars, vous le voudriez. Si le programme doit être utilisé / accédé par d’autres programmes non-C, vous devez prendre en charge l’insensibilité à la casse, mais votre langue est votre choix.

http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Visual_Basic_.NET http://www.vbrad.com/article.aspx?id=65

Je n’ai vu personne commenter votre 2ème question explicite à la fin: “2: est-ce assez convaincant pour moi d’envisager de passer à C # si le cas VB.NET limite d’une manière ou d’une autre ce que je pourrais faire avec du code?”

Je préfère l’approche plus optionnelle que C # permet au programmeur de choisir soit de limiter les options du programmeur. Je préfère fortement le C #, mais pour la seule sensibilité à la casse, je ne penserais même pas à l’apprentissage d’une langue simplement parce qu’elle est sensible à la casse. toutes les fonctionnalités sont ce qui compte, et quand je regarde les avantages de C # et VB.NET, je préfère fortement C #. mais je vais vous donner une vraie perspective équilibrée, biaisée oui, parce que j’ai une préférence, mais je serai honnête sur les inconvénients de C # aussi.

Tout d’abord, les deux langues ont des avantages et des inconvénients. Les différences que vous pouvez faire dans une langue qui ne peut pas être faite dans l’autre langue diminuent car, heureusement, Microsoft améliore les deux langues, et elles ne semblent pas faire preuve de partialité injuste envers l’une ou l’autre langue.

Lorsque C # est apparu pour la première fois, VB n’avait pas ses commentaires XML que vous pouviez mettre avant les méthodes, ce que j’ai aimé 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 sont ajoutées à 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-unes auxquelles je peux penser immédiatement:

1: C # est plus concis et prend moins de frappe. J’ai même vu la bêtise de parler quand la revendication opposée est faite, que VB enregistre la saisie. mais s’il vous plaît écoutez les gens qui vous disent qu’ils utilisent les deux langues, et aucun d’eux n’est rarement utilisé par eux. J’utilise à la fois C # et VB, C # à la maison parce que j’aime ça (et quand je travaille avec C # au travail), et mes demandes de travail plus récentes que j’utilise VB et non C #. donc je reçois plus fréquemment l’utilisation de VB (depuis environ 10 mois maintenant), mais dans mon témoignage personnel, je préfère de beaucoup C #, et en termes de typage réel, VB est considérablement plus typé. Le seul exemple que j’ai lu où quelqu’un a essayé de dire que VB était plus concis, était de donner un exemple “with …” avec une longue variable dans le avec, donc dans VB, vous pourriez simplement utiliser “.property”. c’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 souvent lorsque C # est plus concis, dans la pratique.

mais la plus grande 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 communes. en C # il n’y a pas de mot à taper! 🙂 aussi toutes les instructions ‘end …’ prennent en tapant ce qui dans c #, est généralement une seule accolade ‘}. J’ai lu que certaines personnes affirment que plus de verbosité dans VB.NET est un avantage pour VB puisque plusieurs déclarations / symboles de bloc finaux peuvent être nesteds et se terminer immédiatement l’un à côté de l’autre, mais je ne suis pas du tout d’accord. une personne peut presque toujours écrire un programme mieux en C # ou VB qu’un autre, car la prochaine révision du code pourrait être mieux conçue. cela s’applique à la «confusion entre de nombreuses accolades dans C #» et si les blocs nesteds sont tous du même type que plusieurs IF nesteds, VB rencontre le même problème que dans 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 ma déclaration finale va dans les deux langues. Oui, c’est plus verbeux à 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. Je pense que la clarté du code est très importante.

2: VB n’a pas de commentaires sur plusieurs lignes. Quand je travaillais avec VB, ça ne me dérangeait pas. alors je suis allé à quelques langues de style C. maintenant je retourne principalement en utilisant VB.NET au travail, et ils me manquent. c’est juste quelque chose que vous trouvez commode et que vous devez ensuite perdre. 🙁

3: “andalso” et “orelse” de VB sont plutôt ennuyeux pour taper tout cela quand, en C #, c’est simplement “&&” et “||”. encore une fois, moins de frappe. Ce n’est pas rare dans mon code à la fois en VB et en C #. au contraire, pour les fonctionnalités, OR n’a rien à voir avec OrElse, sauf qu’OrElse est plus rapide pour l’ordinateur, donc si un programmeur utilise simplement Or et And dans VB, alors il produit un code moins optimal pour quelqu’un qui aime la clarté du code. «Ou» est beaucoup plus facile à écrémer que «OrElse».

4: plus de flexibilité dans le placement du code en C #. Quand une ligne est longue et que vous voulez l’enrouler sur la ligne suivante, je déteste le réajustement de mon code par VB.NET. C # le fait un peu, mais je le trouve plus utile en C #, où dans VB, il est beaucoup plus contrôlé. mais c’est plutôt l’IDE VB.NET vs ID C # plutôt que le langage lui-même. mais je ne sais pas si vous voulez les deux ou purement les fonctionnalités de langage sans différences IDE.

5: celui qui me manque vraiment est juste de créer un nouveau bloc de code en C #, je pourrais avoir beaucoup de choses dans une méthode et je veux déclarer une variable dans un très petit bloc de code sans que cette variable soit déclarée en dehors de ce bloc la méthode entière. en C #, nous pouvons simplement créer un nouveau bloc avec ‘{‘ et le terminer par ‘}’. VB n’a pas cette fonctionnalité, mais sa correspondance la plus proche est un bloc inconditionnel «Si vrai alors» et «Fin si». (notez à nouveau l’équivalent de 2 caractères C # vs 18 caractères VB.NET … plus de saisie dans VB.)

6: opérateurs d’auto-incrémentation et de décrémentation: ++ et – comme dans myVariable++ ou ++myVariable ou les versions de décrémentation équivalentes. c’est très pratique … parfois. Voici un exemple de code réel lorsque j’ai raté C # grandement:

 // 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 très bon exemple où les règles C #, c’est plus de code que j’ai é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:  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  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  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.  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.  Public Function IsNotWithin(v&, value1&, value2&) As Boolean Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1) End Function  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  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  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.  Public Function IsNotWithin(v@, value1@, value2@) As Boolean Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1) End Function  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  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  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.  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.  Public Function IsWithin(v&, value1&, value2&) As Boolean Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1) End Function  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  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  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.  Public Function IsWithin(v@, value1@, value2@) As Boolean Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1) End Function 

Perhaps this is enuf evidence that C# is more concise. But not all programmers like conciseness. Some prefer to read "if a < b then ... " because it is more natural to their human language. And that's just fine. Preferences are fine. For me, hand effort is a factor i value, and i think anyone can get used to thinking in any symbols they prefer, for "if" and "then" are symbols of an alphabet, and C#'s "if (condition) statement;" syntax are symbols too. one is just closer to non-programmer's syntax than the other. i prefer the concise one.

I also think needing to use 'c' after character literals in VB to make it a character literal rather than a ssortingng is annoying. I like C#'s conciseness with that much more. when a method requires a character literal, you need to provide a character not a ssortingng with one character length, so sometimes you are forced to use ":"c in VB while in C# it is ':' . i think this is nit-picking tho.

To be fair, i will say there are advantages i like to VB like not having to put empty parentheses after method calls, like Dim nameUpper$ = name.ToUpperInvariant where C# requires the empty parentheses: ssortingng nameUpper = name.ToUpperInvariant() . or double that like sortingmming it too: Dim nameUpper$ = name.Trim.ToUpperInvariant vs ssortingng nameUpper = name.Trim().ToUpperInvariant() . I like VB's concise use of how i just used $ above to dim it ' As Ssortingng' where C# does not have those shortcuts. VB has those shortcuts for Ssortingng, Integer, Long, Decimal, Single, and Double types, but the disadvantage is it is less clear, so i use it with caution. but nevertheless, i prefer concise code.

Well, that's just some thots from this seasoned programmer, and as i consider, this is my programming 'testimony' of C# vs VB. both are nice languages tho, in my opinion. but yes, i still much prefer C#.

ps Since i plan to program for most of my life, i even re-learned to type using the most efficient keyboard: the Dvorak keyboard, which takes about 1/3 the effort to type English than on a Qwerty keyboard. look it up. maybe you might want to switch too. 😉 it made my typing 67% easier! 🙂 I encourage anyone to think outside the box and evaluate better efficiency in your work. The Dvorak Simplified Keyboard Layout and C# has done this for me. 🙂

PSS i would compare the Dvorak and C# to mesortingc as opposed to the Qwerty keyboard layout and VB to the Empirial measurements. Dvorak, mesortingc, and C# are just 'clean'. BUT VB is not really far behind. But it does suffer from needing to be backward compatible to old VB6 code and pre .NET code, like the 'Or' vs 'OrElse', and 'IIF()'.

I finish with a caution. Please be more prudent that listening to people who do not really know what they are talking about. Half of all the cons against both VB and C# are not any issue anymore, and people still post about them being ignorant about what disadvantages really still do exist in the language. The best example i can think of is XML comments for methods using sortingple apostrophe in VB or sortingple slash comment symbols in C#. But please discern for yourself whether a person is speaking from ignorance, or from experience. Personal testimony means they know from their real experience. And after someone has lots of experience in it, then perk up your ears. I have more than 10 years experience in both C# and VB. And it boils down to this: both are (very) good languages. And most the differences, you can see immediately within 5 minutes of reading code. But yes, other features it may take years to find a handicap. And one handicap that i'm aware of (in C#), I can't even think of a real life situation where it would be useful. So perhaps it isn't a handicap after all.

Heureux codage!

VB.NET is case-INsensitive.

Exemples:

1.

 Dim a As Integer Dim A as Integer 

2.

 Sub b() 'Some statement(s) here End Sub Sub B() 'Some statement(s) here End Sub 

3.

 Function c() As Integer 'Some statement(s) here End Function Function C() As Integer 'Some statement(s) here End Function 

These all code will throw a COMPILE-TIME ERROR .

For the 1st example, error will be shown, saying “Local variable ‘A’ is already declared in the current block.”.

While for the 2nd and 3rd example, error will be shown saying “‘Public Sub b()’ has multiple definitions with identical signatures.” and “‘Public Function c() As Integer’ has multiple definitions with identical signatures.”, respectively.

From these errors, note that the errors are thrown at different positions for variables and procedures/functions. For variables, error is thrown at 2nd declaration while for procedures/functions it is thrown at 1st declaration/definition of identical code.

As said by a user in a comment somewhere above, the VB.NET code is continuously checked and/or corrected in background; you can see this error in “Error List” window in VS IDE. And as this is AN ERROR and NOT A WARNING , the code will not comstack until error is resolved.