VB est vraiment insensible à la casse?

Je n'essaie pas de lancer un argument ici, mais pour quelque raison que ce soit, il est généralement dit que Visual Basic est insensible à la casse et les langues C ne le sont pas (et d'une certaine façon, c'est une bonne chose).

Mais voici ma question: Où est exactement Visual Basic case insensible? Quand je tape...

Dim ss As String
Dim SS As String

...dans le Visual Studio 2008 ou Visual Studio 2010 IDE, le second a un avertissement de " variable locale SS est déjà déclarée dans le bloc actuel ". Dans le VBA VBE,il ne déclenche pas immédiatement une erreur, mais corrige tout simplement le cas.

est-ce que je manque quelque chose avec cet argument que Visual Basic n'est pas sensible à la casse? (Aussi, si vous savez ou le soin de répondre, pourquoi serait-ce une mauvaise chose?)

pourquoi je pose cette question?

J'ai utilisé Visual Basic dans beaucoup de ses dialectes depuis des années, parfois comme un amateur, parfois pour les petits programmes liés aux entreprises groupe de travail. Comme au cours des six derniers mois, J'ai travaillé sur un gros projet, beaucoup plus grand que ce que je pensais. Beaucoup du code source de l'échantillon là-bas est en C#. Je n'ai pas de combustion désir d'apprendre C#, mais s'il y a choses que je suis absent dehors sur que C# offre que Visual Basic ne fait pas (un contraire serait VB.NET les offres XML Literals ), alors j'aimerais savoir plus sur cette fonctionnalité. Donc, dans ce cas, on fait souvent valoir que C les langues sont sensibles à la casse et C'est bon et visuel de base est Cas insensible et qui est mauvais. J'avais comme savoir...

  1. comment cela est-Visual Basic cas insensible parce que chaque exemple unique dans l'éditeur de code devient cas sensititive (sens le boîtier est corrigé) si je veux ou pas et
  2. est-ce assez convaincant pour moi de envisagez de passer à C # if VB.NET cas est en quelque sorte limitant ce que je pourrais faire avec code?
109
demandé sur Peter Mortensen 2010-02-20 07:03:15

14 réponses

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

comme Jonathan dit , quand vous programmez vous pouvez penser VB.NET as case-insensible mis à part string-comparisons, XML, et quelques autres situations...

je pense que tu t'intéresses à ce qu'il y a sous le capot. Eh bien, le langage commun de. Net L'exécution est sensible à la casse , et VB.NET le code dépend de l'exécution, de sorte que vous pouvez voir qu'il doit être sensible à la casse à l'exécution, par exemple quand il cherche des variables et des méthodes.

le VB.NET compilateur et éditeur vous ont laissé ignorer cela-parce qu'ils corriger le cas dans votre code.

si vous jouez avec des fonctionnalités dynamiques ou de late-binding (Option Strict Off) , vous pouvez prouver que le temps d'exécution sous-jacent est sensible à la casse. Une autre façon de voir cela est de réaliser que les langages sensibles à la casse comme C# utilisent le même runtime, donc le runtime supporte évidemment la case-sensitivity.

EDIT 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 pour qu'il ait ss et SS et voyez ce que fait le compilateur.

MODIFIER Citation de Jeffrey Richter dans le .NET Cadre des lignes Directrices de Conception à la page 45.

pour être clair, le CLR est en fait sensible à la casse. Un peu de programmation les langues, comme Visual Basic, sont Cas insensible. Lorsque le compilateur Visual Basic est en essayant de résoudre un appel de méthode à un type défini dans une casse le langage comme C#, le compilateur (pas le CLR) détermine le cas réel de la méthode nom et l'intègre dans métadonnées. Le CLR ne sait rien à propos ce. Maintenant, si vous utilisez la réflexion pour lier à une méthode, la réflexion APIs offre la capacité de faire non à la casse des recherches. C'est le mesure dans laquelle le PLC offre l'insensibilité à la casse.

98
répondu MarkJ 2017-05-23 12:10:30

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

comme langue, VB.NET est certainement un cas insensible en ce qui concerne les identificateurs. L'appel DateTime.Parse et datetime.parse se liera au même code. Et contrairement aux langages comme C#, il n'est pas possible de définir des méthodes ou des types qui ne diffèrent que par cas.

comme IDE, VB.NET les tentatives de préserver le cas de identificateurs existants quand il Liste joliment un bloc de code. Les jolies listes se produisent chaque fois que vous vous éloignez de la ligne logique courante du code. Dans ce cas , vous quittez la deuxième déclaration de SS , les jolis avis lister Il ya un identifiant existant avec ce nom et le corrige pour avoir cas correspondant.

ce comportement, cependant, est purement fait comme une valeur ajoutée utilisateur. Elle ne fait pas partie de la langue de base.

21
répondu JaredPar 2012-04-14 22:33:35

VB est la plupart insensible à la casse, mais il y a des exceptions. Par exemple, la littéralité et la compréhension du XML sont sensibles à la casse. Les comparaisons de chaînes de caractères sont habituellement sensibles à la casse, contrairement à T-SQL, mais il y a un commutateur de compilateur pour rendre les comparaisons de chaînes de caractères insensibles à la casse. Et bien sûr, il y a les cas de bord lorsqu'il s'agit de Héritage, COM, et dynamique langage Runtime.

16
répondu Jonathan Allen 2010-02-20 04:55:11

Oui, le VB.NET compilateur traite les identificateurs d'une manière insensible à la casse. Et oui, cela peut causer des problèmes quand il consomme des assemblages qui ont été écrits dans une autre langue ou utilise des composants COM. Le premier cas est couvert par le Common Language Specification . La règle pertinente est la suivante:

pour deux identificateurs à prendre en considération distinctes, elles doivent différer de plus que leur cas.

le cas COM est assez grossièrement pris en charge par le type library builder, il force le boîtier d'identificateurs 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 un nom de méthode "Index" à être recasé en "index". Cela a produit plutôt beaucoup de grattage de la tête, comme vous pourriez imaginer:)

9
répondu Hans Passant 2012-05-22 12:53:04

VB est "151910920 cas" préserver (dans l'IDE), mais casse . C'est comme un système de fichiers Windows. Bonjour.txt et bonjour.txt sont considérés comme le même nom de fichier.

l'IDE suppose que la déclaration une variable est le cas" correct " pour cette variable, et ajuste chaque instance de cette variable correspondent à la déclaration. Il le fait pour des raisons de concision et de cohérence, mais pas pour des raisons de 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 tout de même. Vous pouvez également utiliser n'importe quel éditeur de texte pour écrire du code qui se compilera très bien dans différents cas.

Une note:

Plus les GENS penser dans une casse. Quand nous voyons que le mot "chien", le mot est traduit dans le sens de nos esprits. Le sens du mot n'est pas basé sur le cas (c.-à-d. indépendamment de si épeler "chien", "chien", ou "chien" aboie encore.) ORDINATEURS voir les mots discrets, sacs de bits. Les majuscules et les minuscules sont des motifs de bits différents, et sont donc différents.

é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 et la sensibilité à la casse est davantage une question d'humains qui adaptent leur façon de penser aux contraintes d'une machine.

6
répondu Andrew Neely 2015-11-19 18:05:28

Cela fait partie de l'éditeur que vous utilisez, ils peuvent se comporter différemment, mais le fait est que Visual Basic est vraiment langage cas-insensible. Donc, ss et SS sont les mêmes.

, jetez un oeil à VB.NET Bases tutoriel pour plus d'informations :)

5
répondu Sarfraz 2012-04-14 22:31:39

Je ne suis pas sûr de vous comprendre? VB est insensible à la casse, donc ss et SS sont la même variable, de sorte que 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 le sont.

3
répondu Michael Stum 2010-02-20 04:06:31

Oui, VB est insensible à la casse. Il jette parfois ceux qui ne sont pas utilisés pour un peu d'une boucle.

1
répondu Xorlev 2010-02-20 04:07:15

on n'a pas besoin d'essayer si fort en VB.NET pour créer le code avec des majuscules / minuscules différentes "orthographe" d'un identificateur. Changer le boîtier d'un identifiant dans le fichier où il est déclaré sans utiliser la fonction "Rename" ne provoquera pas la mise à jour du nom dans d'autres fichiers, mais éditer toute ligne qui contient le nom le rendra conforme à la présente définition.

de cette façon, on peut déterminer que VB.NET est le plus souvent insensible à la casse, mais elle met le cas des identificateurs à la disposition du CLR qui peut utiliser cette information de manière sensible.

1
répondu supercat 2012-04-14 22:34:31

Je ne peux offrir que ceci, qui comme je me souviens de mes livres de texte de programmation au début des années 80, est que les langages senstifs de cas étaient, (à l'époque) strictement destinés à réduire les erreurs de temps de compilation. C'est-à-dire que la "rigueur" visait à développer une discipline de codage plus précise. Comme il s'est avéré l'ajout de l'étiquetage approprié des variables, des classes, des méthodes, des fonctions, et tout ce que vous voulez y jeter, a évolué ainsi.

I rappelons que presque tous ces livres incluaient un modèle recommandé pour la capitalisation de tête, minuscules, etc. Comme nous le savons tous, une grande partie de ce qui a été jeté ou devrais-je dire, ignoré dans la pratique, sauf pour les maisons de production haut de gamme, et des solutions de cas, ou pour ceux qui ont atteint un niveau de compétence plus élevé. Je pense que tout le monde connaît cette courbe d'apprentissage.

étant donné l'avancement de ces langauges et IDE, la meilleure question devient, quelle langue améliore mon dev temps? Bien sûr, si vous n'êtes pas familier avec chacun des différents langs, vos options sont limitées.

1
répondu htm11h 2013-07-10 12:52:12

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

" est-ce assez convaincant pour moi d'envisager de passer à C # if VB.NET l'affaire limite ce que je peux faire avec le code?"

créer un service Web de la WCF en utilisant C#. Créer un DataContract (1 Classe). Une avec la propriété" string email". Une autre avec" string Email " comme autre propriété. Votre choix de comprendre comme un courriel personnel ou un courriel de bureau. Ou ça pourrait être dans deux contrats de données différents.

pour C# c'est très bien. Le service web est créé fine. Un programme C# peut facilement créer une WSDL et tout est parfait.

maintenant, essayez de créer une WSDL avec VB (n'importe quelle version). Il sera dit "email" est déjà déclaré et la génération WSDL échoue.

comme tout le monde j'ai supposé que c'était un inconvénient dans le langage VB. Mais!!!

utilisez FxCOP et analysez le code C d'origine. FxCOP dit que l'utilisation du courriel est un problème. Recommande d'utiliser un nom différent soutenant l'insensibilité de cas. À noter également qu'à ce jour.le cadre de réseau compte 106 langages de programmation et il y a de nombreux langages ayant une sensibilité à la casse. Nous évoluons tous vers le cloud et voulons que nos services soient accessibles à toutes les plateformes/langues de programmation.

donc être sensible à la casse est votre choix au sein de votre programme et si vous êtes C guy vous le souhaitez. Si le programme va être utilisé/accédé par d'autres programmes non c vous besoin de soutenir l'insensibilité cas, 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

1
répondu Venkat 2013-09-27 14:15:46

Je n'ai vu personne commenter sur votre 2ème question explicite à la fin: "2: est-ce assez convaincant pour moi d'envisager de passer à C # if VB.NET l'affaire limite ce que je peux faire avec le code?"

je préfère l'approche plus d'options que C# laisse le programmeur choisir si plutôt que de limiter les options du programmeur. je préfère fortement C#, mais pour la sensibilité de cas seul, Je ne penserais même pas qu'il proche d'apprendre une langue juste parce qu'il est sensible à Cas. toutes les caractéristiques sont ce qui importe, et quand je regarde les avantages des deux, C# et VB.NET, je préfère C#. mais je vais vous donner une perspective vraiment équilibrée, partiale oui, parce que j'ai une préférence, mais je vais être 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 peut pas être fait dans l'autre s'amenuisent car, heureusement, Microsoft améliore les deux langues, et ils semblent ne pas montrer injuste partialité envers l'une ou l'autre langue.

quand C# est sorti pour la première fois, VB n'avait pas ses commentaires XML que vous pouviez mettre avant les méthodes, que j'ai adoré dans C#. je détestais ça. 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 de MS développe à la fois C# et VB, il est donc logique que les fonctionnalités devraient devenir tout à fait similaire.)

mais vous j'ai demandé ce que C# avait que VB n'avait pas. en voici quelques-unes auxquelles je pense tout de suite:

1: C# est plus concis et prend moins de frappe.. dans BEAUCOUP de façons! j'ai même vu de la stupidité parler quand on prétend le contraire, que VB évite de taper. mais s'il vous plaît écouter les gens qui vous disent qu'ils utilisent les deux langues, et ce n'est que rarement utilisé par eux. j'utilise C# et VB, C# à la maison parce que je l'aime (et quand je travaille avec C# au travail), et mon plus récent demandes de travail que j'utilise VB et non C#. je commence donc à utiliser plus souvent VB maintenant (depuis environ 10 mois maintenant), mais dans mon témoignage personnel, je préfère beaucoup C#, et en termes de Dactylographie réelle, VB est considérablement plus Dactylographie. le seul exemple que j'ai lu où quelqu'un a essayé de dire que VB était plus concis, c'était de donner un "avec"..."exemple avec une variable longue dans le with, donc dans VB, vous pouvez juste utiliser".propriété". c'est stupide de prétendre que VB a besoin de moins de Dactylographie. il y a quelques choses (et pas seulement cet exemple) où VB est plus courte, mais beaucoup plus de fois où C# est plus concis, dans la pratique réelle.

mais la plus grande raison pour laquelle je crois que C# est plus concis, c'est les déclarations verbeuses de VB "si/alors". si les déclarations sont communs. dans C# il n'y a pas de mot "then" à taper! :) 'fin ...'les déclarations prennent la dactylographie qui en c#, est généralement juste une brace de fermeture'}'. j'ai lu que certaines personnes revendiquent cette plus verbosité dans VB.NET est un avantage pour VB puisque plusieurs les énoncés/symboles des blocs de fermeture peuvent être imbriqués 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 dans C# ou VB qu'un autre programmeur parce que la prochaine révision du code pourrait être mieux conçue. cela s'applique à la 'confusion de nombreux accolades de fermeture en C#' plus si les blocs imbriqués sont tous du même type comme plusieurs imbriqués alors VB souffre du même problème qu'il a en C#. ce n'est pas un avantage en VB. cette situation est c'est précisément la raison pour laquelle j'aime Commenter ce que mon symbole de clôture ou ma déclaration finale va avec 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 fondés sur le jugement et liés à des situations particulières. je pense que la clarté du code est très importante.

2: VB n'a pas les commentaires multi-lignes. quand je travaillais avec VB, ça ne me dérangeait pas. puis je suis allé à quelques langues de style C. maintenant je suis de retour principalement en utilisant VB.NET au travail, et je les manquer. c'est juste quelque chose qui vous conviennent, puis ont à perdre. : (

3: VB "andalso" et "orelse' est plutôt gênant pour saisir toutes qu'en C#, il est tout 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é, ' ou ' vs 'OrElse' n'a généralement pas d'importance sauf que 'OrElse' est plus rapide pour l'ordinateur, donc si un programmeur utilise juste ' ou 'et' et' en VB, alors il produit du code moins optimal pour quelqu'un qui aime la clarté du code. "Ou" est beaucoup plus facile à esquiver que "OrElse".

4: plus de flexibilité dans le placement de code dans C#. quand une ligne est trop longue et que vous voulez enchaîner sur la ligne suivante, je déteste VB.NET's 'contrôler' de réajuster mon code. C# le fait un peu, mais je le trouve plus utile en C#, où en VB, il est beaucoup plus contrôlant. mais c'est plus de la VB.NET IDE vs C# IDE plutôt que la langue elle-même. mais je ne sais pas si vous voulez les deux ou purement les caractéristiques de la langue sans différences IDE.

5: un qui me manque vraiment c'est juste de créer un nouveau bloc de code en C#, j'ai peut-être beaucoup de choses à faire dans une méthode et je veux déclarer une variable dans un très petit bloc de code mais pas que cette variable soit déclarée en dehors de ce bloc dans toute la méthode. dans C#, nous pouvons simplement créer un nouveau bloc avec '{' et le terminer avec '}'. VB n'a pas de telle fonctionnalité, mais sa correspondance la plus proche est un bloc inconditionnel "If True Then" et "End If". (notez les 2 caractères C# vs 18 caractère VB.NET encore l'équivalent... plus de Dactylographie en VB.)

6: opérateurs d'incrément et de décrément automatique: ++ et -- comme dans myVariable++ ou ++myVariable ou les versions équivalentes de décrément. cela s'avère très pratique... parfois. voici un exemple de code réel quand j'ai manqué 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ù c # règles, 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 bonnes. Pour moi, l'effort de la main est un facteur que j'apprécie, et je pense que n'importe qui peut s'habituer à penser dans n'importe quel symbole qu'ils préfèrent, pour "si" et "puis" sont des symboles d'un alphabet, et C#'S "Si (condition) déclaration;" syntaxe sont des symboles aussi. on est juste plus près de syntaxe du non-programmeur que l'autre. je préfère la concision.

je pense aussi que la nécessité d'utiliser 'c' après les caractères littéraux en VB pour en faire un caractère littéral plutôt qu'une chaîne est ennuyante. J'aime beaucoup la concision de C#. quand une méthode nécessite un caractère littéral, vous devez fournir un caractère pas une chaîne avec une longueur de caractère, donc parfois vous êtes forcé d'utiliser ":"c dans VB alors que dans C# il est ':' . je pense que c'est nit-picking tho.

pour être honnête, je dirai qu'il y a des avantages que J'aime à VB comme de ne pas avoir à mettre des parenthèses vides après les appels de méthode, comme Dim nameUpper$ = name.ToUpperInvariant où C# nécessite les parenthèses vides: string nameUpper = name.ToUpperInvariant() . ou le double: Dim nameUpper$ = name.Trim.ToUpperInvariant vs string nameUpper = name.Trim().ToUpperInvariant() . J'aime L'utilisation concise de VB de la façon dont je viens d'utiliser $ ci-dessus pour le dim 'As String' où C# n'a pas ces raccourcis. VB a ces raccourcis pour la chaîne, entier, Long, décimal, Simple et Double types, mais l'inconvénient est qu'il est moins clair, j'ai donc l'utiliser avec prudence. mais néanmoins, je préfère code concis.

Eh bien, c'est juste quelques trucs de ce programmeur chevronné, et comme je 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 quand même beaucoup C#.

p. S. Depuis que j'ai l'intention de programmer pour la plupart de ma vie, j'ai même ré-appris à dactylographier en utilisant le plus efficace clavier: le clavier Dvorak, qui prend environ 1/3 de l'effort pour taper l'anglais que sur un clavier Qwerty. le regarder. peut-être que vous pouvez modifier. ;) il a fait ma taper 67% de plus facile! :) J'encourage tout le monde à sortir des sentiers battus et à évaluer une meilleure efficacité de votre travail. La disposition simplifiée du clavier Dvorak et C# l'a fait pour moi. :)

P. S. S. Je comparerais le Dvorak et C# à metric par opposition à la disposition du clavier Qwerty et VB à L'Empirial mesure. Dvorak, metric, et C# sont juste 'clean'. Mais VB n'est pas vraiment loin derrière. Mais il souffre d'avoir besoin d'être rétrocompatible avec le vieux code VB6 et pré.net, comme le 'ou' vs 'OrElse', et 'IIF ()'.

je finis par une mise en garde. Soyez plus prudent que d'écouter des gens qui ne savent pas vraiment de quoi ils parlent. La moitié de tous les contre à la fois VB et C# sont pas tout problème plus, et les gens postent encore sur le fait qu'ils soient ignorants des désavantages qui existent encore dans la langue. Le meilleur exemple que je puisse imaginer est XML comments pour les méthodes utilisant triple apostrophe dans VB ou triple Slash les symboles de commentaire dans C#. Mais s'il vous plaît discerner par vous-même si une personne parle par ignorance, ou par expérience. Témoignage personnel signifie qu'ils savent de leur expérience réelle. Et après quelqu'un qui a beaucoup d'expérience, alors relevez vos oreilles. J'ai plus de 10 années d'expérience dans les C# et VB. Et cela se résume à ceci: les deux sont (très) bonnes langues. Et la plupart des différences, vous pouvez voir immédiatement dans les 5 minutes de code de lecture. Mais oui, d'autres fonctions qu'il peut prendre des années pour trouver un handicap. Et un handicap dont je suis conscient (en C#), Je ne peux même pas penser à une situation réelle où il serait utile. Alors peut-être que ce n'est pas un handicap, après tout.

bon codage!

0
répondu Shawn Kovac 2014-01-24 22:42:55

VB.NET est insensible à la casse.

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

tous code va lancer une ERREUR de COMPILATION .

pour le premier exemple, l'erreur sera affichée, en disant" la variable locale 'A' est déjà déclarée dans le bloc courant.".

alors que pour les Deuxième et troisième exemple, l'erreur sera affichée en disant "'public Sub b ()' a des définitions multiples avec des signatures identiques."et "'Fonction publique c () comme entier' a plusieurs définitions avec des signatures identiques.", respectivement.

à partir de ces erreurs, noter que les erreurs sont lancées à des positions différentes pour les variables et les procédures/fonctions. Pour les variables, l'erreur est lancée à la 2ème déclaration tandis que pour les procédures/fonctions elle est lancée à la 1ère déclaration/définition de un code identique.

comme dit par un utilisateur dans un commentaire quelque part au-dessus, le VB.NET le code est continuellement vérifié et / ou corrigé en arrière-plan; vous pouvez voir cette erreur dans la fenêtre "Error List" dans VS IDE. Et comme c'est une erreur et pas un avertissement , le code ne sera pas compilé jusqu'à ce que l'erreur soit résolue.

0
répondu Nikunj Bhatt 2014-06-19 12:09:02

cacher des symboles (par exemple: local hides field) est également insensible à la casse.

voici un exemple :

Public Class C
    Public Name As String

    Public Function M(name As String) As Boolean
        Return String.Equals(name, Name) ' case differs
    End Function
End Class

le VB.NET la sortie du compilateur est décomposée en (et donc équivalente à) le C# suivant:

public class C
{
    public string Name;

    public bool M(string name)
    {
        return string.Equals(name, name); // both lowercase
    }
}

string.Equals est passé deux fois dans le champ. Le local est caché, quel que soit le cas. Le langage est insensible à la casse.

à explicitement référence au membre a, tel que ce champ, vous devez déréférencer le Membre via Me :

Return String.Equals(name, Me.Name) ' differentiate field from local
0
répondu Drew Noakes 2018-09-10 13:04:51