VB est-il vraiment insensible à la casse ?

Question

Je n'essaie pas de lancer une polémique ici, mais pour une raison quelconque, on dit généralement que Visual Basic est insensible à la casse et que les langages C ne le sont pas (et que c'est en quelque sorte une bonne chose).

Mais voici ma question : Où exactement Visual Basic est-il insensible à la casse ? Quand je tape...

Dim ss As String
Dim SS As String

...dans le Visual Studio 2008 o Visual Studio 2010 IDE, le second a un avertissement de " Variable locale SS est déjà déclaré dans le bloc actuel ". Dans le VBE VBA, il n'y a pas d'erreur immédiate, mais plutôt une correction automatique de la situation.

Est-ce que je rate quelque chose ici avec cet argument que Visual Basic n'est pas sensible à la casse ? (Par ailleurs, si vous le savez ou si vous souhaitez répondre, pourquoi serait-ce une mauvaise chose ?)

Pourquoi est-ce que je pose cette question ?

J'ai utilisé Visual Basic sous plusieurs de ses formes dialectes depuis des années, parfois comme hobbyiste, parfois pour de petites programmes liés à l'entreprise dans un groupe de travail. Au cours des six derniers mois, j'ai travaillé sur un grand projet, beaucoup plus grand que ce que j'avais prévu. Une grande partie de l'échantillon de code source là-bas est en C#. Je n'ai pas de désir ardent d'apprendre le C#, mais s'il y a des choses qui me manquent des choses que je manque et que C# que Visual Basic n'offre pas (à l'inverse, VB.NET offrirait serait que VB.NET offre Littéraux XML ), alors j'aimerais en savoir sur cette fonctionnalité. Ainsi, dans ce Dans ce cas, on dit souvent que les langages C sont sensibles à la casse et c'est bien et que Visual Basic est insensible à la insensible à la casse et que c'est mauvais. J'aimerais voudrais savoir...

1. Comment exactement le Visual Basic insensible à la casse puisque chaque chaque exemple dans l'éditeur de code devient sensible à la casse (ce qui signifie la casse est corrigée) que je le veuille ou non que je le veuille ou non.
2. Est-ce assez convaincant pour que je envisager de passer à C# si le cas VB.NET limite en quelque sorte ce que je pourrais faire avec le code ?

Answer 1

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

Comme Jonathan dit Dans le cadre de la programmation, vous pouvez considérer que VB.NET ne tient pas compte de la casse, sauf pour les comparaisons de chaînes de caractères, le XML et quelques autres situations...

Je pense que vous êtes intéressé par ce qu'il y a sous le capot. Eh bien, le Common Language Runtime de .NET est sensible à la casse Le code VB.NET s'appuie sur le runtime, vous pouvez donc constater qu'il doit respecter la casse au moment de l'exécution, par exemple lorsqu'il recherche des variables et des méthodes.

Le compilateur et l'éditeur VB.NET vous permettent d'ignorer cela - parce qu'ils corriger l'affaire dans votre code.

Si vous jouez avec les fonctionnalités dynamiques ou les liaisons tardives (Option Strict Off), vous pouvez prouver que le runtime sous-jacent est sensible à la casse. Une autre façon de voir les choses est de réaliser que les langages sensibles à la casse comme C# utilisent le même runtime, donc le runtime supporte évidemment la sensibilité à la casse.

EDITAR Si vous voulez retirer l'IDE de l'équation, vous pouvez toujours compiler à partir de la ligne de commande . Modifiez votre code dans Bloc-notes donc il a ss y SS et voir ce que le compilateur fait.

EDITAR Citation de Jeffrey Richter en el Directives de conception de .NET Framework page 45.

Pour être clair, le CLR est en fait sensible à la casse. Certains langages de programmation langage de programmation, comme Visual Basic, sont insensibles à la casse. Lorsque le compilateur Visual Basic essaie de résoudre un appel de méthode à un type défini dans un langage sensible à la comme le C#, le compilateur (et non pas la le CLR) détermine la casse réelle du nom de la méthode et l'incorpore dans le fichier métadonnées. Le CLR ne sait rien de rien de tout cela. Maintenant, si vous utilisez la réflexion pour vous lier à une méthode, les API de réflexion offre la possibilité de faire des recherches insensibles à la casse. C'est la mesure dans laquelle le CLR offre la sensibilité à la casse.

Answer 2

Une partie du problème ici est que vous devez séparer le langage de l'expérience de l'IDE.

En tant que langue, VB.NET est certainement insensible à la casse en ce qui concerne les identifiants. Appeler DateTime.Parse y datetime.parse se lieront exactement au même code. Et contrairement à des langages comme C#, il n'est pas possible de définir des méthodes ou des types qui ne diffèrent que par la casse.

En tant qu'IDE, VB.NET tente de préserver la casse des identifiants existants lorsqu'il établit une jolie liste d'un bloc de code. Les jolies listes se produisent chaque fois que vous vous éloignez de la ligne de code logique actuelle. Dans ce cas, vous sortez de la deuxième déclaration de SS Si le nom de l'identifiant n'a pas été modifié, la liste de contrôle remarque qu'il existe déjà un identifiant avec ce nom et le corrige pour qu'il corresponde à la casse.

Ce comportement, cependant, est purement fait comme une valeur ajoutée pour l'utilisateur. Il ne fait pas partie du noyau du langage.

Answer 3

VB est principalement insensible à la casse, mais il y a des exceptions. Par exemple, les littéraux XML et la compréhension sont sensibles à la casse. Les comparaisons de chaînes de caractères sont généralement sensibles à la casse, contrairement à T-SQL, par exemple, mais il existe des commutateurs de compilateur pour rendre les comparaisons de chaînes de caractères insensibles à la casse. Et bien sûr, il y a les cas limites lorsqu'il s'agit d'héritage, de COM et de Dynamic Language Runtime.

Answer 4

Oui, le compilateur VB.NET traite les identifiants de manière insensible à la casse. Et oui, cela peut poser des problèmes lorsqu'il consomme des assemblages qui ont été écrits dans un autre langage ou utilise des composants COM. Le premier cas est couvert par le Spécification du langage commun . La règle pertinente est la suivante :

Pour que deux identifiants soient considérés comme distincts, ils doivent différer par plus que par leur casse.

Le cas de COM est assez grossièrement pris en charge par le constructeur de la bibliothèque de types, il force le casing des identifiants avec le même nom à être identique. Même lorsque ces identificateurs ont des rôles différents. En d'autres termes, un paramètre de méthode avec le nom "index" forcera le nom de méthode "Index" à être recasé en "index". Comme vous pouvez l'imaginer, cela a donné lieu à de nombreuses prises de tête :)

Answer 5

VB est préservation du cas (dans l'IDE) mais insensible à la casse . C'est comme le système de fichiers de Windows en quelque sorte. Hello.txt et hello.txt sont considérés comme étant le même nom de fichier.

L'IDE part du principe que la déclaration d'une variable est le cas "correct" pour cette variable, et adapte chaque instance de cette variable à la déclaration. Il le fait pour des raisons d'esthétique et de cohérence, mais pas pour des raisons fonctionnelles.

J'ai vu plusieurs cas où la casse n'était pas automatiquement modifiée pour correspondre à la déclaration, et l'instruction fonctionne tout de même. Vous pouvez également utiliser n'importe quel éditeur de texte pour écrire du code qui sera compilé sans problème dans différents cas.

Un aparté :

Le plus PEOPLE penser de manière insensible à la casse. Lorsque nous voyons le mot "chien", le mot est traduit en signification dans notre esprit. Le sens du mot n'est pas basé sur la casse (c'est-à-dire que peu importe si on l'écrit "DOG", "DoG" ou "dOG", il aboie toujours). ORDINATEURS voient les mots comme des sacs discrets de bits. Les majuscules et les minuscules sont des modèles de bits différents, et sont donc différentes.

Étant donné que la plupart des programmeurs sont des humains, l'insensibilité à la casse semble plus adaptée à la façon dont les gens pensent, tandis que la sensibilité à la casse concerne plutôt les humains qui adaptent leur façon de penser aux contraintes d'une machine.