Est VB vraiment insensible à la casse?
Je n'essaie pas de lancer un argument ici, mais pour une raison quelconque, il est généralement indiqué que Visual Basic ne respecte pas la casse ni les langages C (et en quelque sorte, c'est une bonne chose).
Mais voici ma question: Où Visual Basic est-il insensible à la casse? Quand je tape ...
Dim ss As String
Dim SS As String
... dans Visual Studio 2008 ou Visual Studio 2010 IDE, le second comporte un avertissement de "la variable locale SS est déjà déclarée dans le bloc actuel}". Dans VBA VBE, cela ne déclenche pas immédiatement une erreur, mais corrige simplement le cas.
Me manque-t-il quelque chose ici avec cet argument que Visual Basic n'est pas sensible à la casse? (En outre, si vous savez ou souhaitez répondre, pourquoi cela serait-il une mauvaise chose?)
Pourquoi je pose même cette question?
J'ai utilisé Visual Basic dans bon nombre de ses dialectes .__ depuis des années, parfois en tant que Amateur, parfois pour de petits programmes liés aux entreprises dans un groupe de travail Au cours des six derniers mois, Je travaillais sur un grand projet, Beaucoup plus gros que prévu. Une grande partie des exemples de code source disponibles est en C #. Je n'ai pas de désir brûlant D'apprendre le C #, mais s'il y a des choses que je manque sur ce C # Offre que Visual Basic ne le fait pas (un opposé Serait VB .NET propose XML Literals ), alors j'aimerais en savoir plus sur cette fonctionnalité. Ainsi, dans cettecase, il est souvent avancé que les langages C Sont sensibles à la casse et Que c'est bon et que Visual Basic est sensible à la casse Et c'est mauvais. J'aimerais savoir...
- comment est exactement Visual Basic insensible à la casse car chaque exemple unique dans l'éditeur de code devient sensible à la casse (ce qui signifie le cas est corrigé) si je le veux ou pas et
- est-ce assez convaincant pour que envisage de passer à C # si le cas VB.NET limite en quelque sorte ce que je pourrais faire avec du code?
La différence entre VBA et VB.NET est simplement due au fait que VB.NET se compile en permanence en arrière-plan. Vous obtiendrez une erreur lors de la compilation de la VBA.
Comme Jonathan dit , lors de la programmation, vous pouvez penser à VB.NET comme insensible à la casse, à l'exception des comparaisons de chaînes, de XML et de quelques autres situations ...
Je pense que vous êtes intéressé par ce qui est sous le capot. Eh bien, le runtime du langage commun .NET est sensible à la casse, et le code VB.NET repose sur le runtime, vous pouvez donc voir qu'il doit être sensible à la casse au moment de l'exécution, par exemple. quand il cherche des variables et des méthodes.
Le compilateur et l'éditeur VB.NET vous ont laissé ignorer cela, car ils corrigent la casse dans votre code.
Si vous jouez avec des fonctionnalités dynamiques ou une liaison tardive (Option Strict 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. Le runtime prend donc évidemment en charge la sensibilité à la casse.
EDIT Si vous souhaitez extraire le IDE de l'équation, vous pouvez toujours compiler à partir de la ligne de commande . Editez votre code dans Notepad donc il a ss et SS et voyez ce que fait le compilateur.
EDIT Citation de Jeffrey Richter dans les Lignes directrices pour la conception du .NET Framework page 45.
Pour être clair, le CLR est en fait sensible aux majuscules et minuscules. Un peu de programmation les langues, comme Visual Basic, sont des cas insensible. Lorsque le compilateur Visual Basic est essayer de résoudre un appel de méthode à un type défini dans une casse Comme le langage C #, le compilateur (pas le CLR) résout le cas réel du nom de la méthode et l'intègre dans métadonnées. Le CLR ne sait rien à propos de ce. Maintenant, si vous utilisez la réflexion se lier à une méthode, la réflexion Les API offrent la possibilité de faire recherches insensibles à la casse. C'est le mesure dans laquelle le CLR offre 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 pour les identificateurs. L'appel de DateTime.Parse et datetime.parse sera lié 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 la casse.
En tant qu'EDI, VB.NET tente de conserver la casse des identifiants existants lorsqu'il liste 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 portant ce nom et le corrige pour qu'il ait la casse correspondante.
Ce comportement, cependant, est purement effectué en tant qu’ajout de valeur utilisateur. Cela ne fait pas partie de la langue principale.
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 sont généralement sensibles à la casse, contrairement à T-SQL, mais il existe des commutateurs de compilation pour rendre les comparaisons de chaînes insensibles à la casse. Et bien sûr, il y a les cas Edge lorsqu'il s'agit d'héritage, de COM et de Dynamic Language Runtime.
Oui, le compilateur VB.NET traite les identificateurs sans tenir compte de la casse. Et oui, cela peut poser des problèmes lorsqu'il consomme des assemblys é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:
Pour que deux identificateurs soient considérés distincts, ils doivent différer par plus que juste leur cas.
Le cas de COM est assez grossièrement pris en charge par le constructeur de la bibliothèque de types, il force le casse des identificateurs avec le 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 portant le nom "index" force le nom de méthode "Index" à être redéfini sur "index". Cela a produit pas mal de maux de tête, comme vous pouvez l'imaginer :)
VB est conserve la casse (dans l'EDI) mais insensible à la casse. C'est un peu comme le système de fichiers Windows. Hello.txt et hello.txt sont considérés comme le même nom de fichier.
Le IDE suppose que la déclaration d'une variable est le cas "correct" pour cette variable et ajuste chaque instance de cette variable pour qu'elle corresponde à la déclaration. Il le fait pour des raisons de pureté 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 de la même manière. Vous pouvez également utiliser n’importe quel éditeur de texte pour écrire du code qui compilera parfaitement dans différents cas.
Une note de côté:
La plupart des PERSONNES pensent sans distinction de casse. Quand nous voyons le mot "chien", le mot est traduit en sens dans nos esprits. La signification de la Parole n’est pas basée sur la casse (c’est-à-dire qu’il soit écrit "DOG", "DoG" ou "DOG" aboie toujours.) ORDINATEURS voient les mots sous forme de sacs distincts. Les majuscules et les minuscules sont des modèles de bits différents et sont donc différents.
Étant donné que la plupart des programmeurs sont des êtres humains, l'insensibilité à la casse semble plus adaptée à la façon dont les gens pensent et la sensibilité à la casse concerne davantage les humains à adapter 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 en réalité langage insensible à la casse. Donc, ss et SS sont identiques.
Veuillez consulter le didacticiel Principes de base de VB.NET pour plus d'informations :)
Je ne suis pas sûr de te comprendre? VB ne respecte pas la casse, donc ss et SS sont la même variable. Le compilateur se plaint donc correctement que vous ayez à nouveau déclaré la variable.
Je pense que les variables ne sont pas sensibles à la casse, mais les noms de fonction le sont.
Oui, VB est insensible à la casse. Il jette parfois ceux qui ne sont pas habitués pendant un moment.
Je ne peux qu'offrir ce qui, comme je me souviens de mes livres de programmation au début des années 80, est que les langages senstive étaient (à l'époque) strictement 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 approprié des variables, des classes, des méthodes, des fonctions et de tout ce que vous souhaitez ajouter, a également évolué.
Je me souviens que presque tous ces livres incluaient un modèle recommandé pour les majuscules majuscules, les minuscules, etc. Les 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.
Etant donné l’avancement de ces langues et des IDE, la meilleure question est de savoir quelle langue améliore mon temps de développement? Bien sûr, si vous ne connaissez pas chacun des différents langs, vos options sont limitées.
Il n'est pas nécessaire d'essayer dans 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" ne provoquera pas la mise à jour du nom dans d'autres fichiers, bien que la modification d'une ligne contenant le nom le rende conforme à la définition actuelle.
De cette manière, on peut déterminer que VB.NET est généralement 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 vais essayer de répondre à votre deuxième question.
"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?"
Créez un WebService WCF en utilisant C #. Créez un DataContract (1 Class). Une avec la propriété "string email". Une autre avec "chaîne Email" comme une autre propriété. Votre choix à comprendre comme email personnel ou email de bureau. Ou cela pourrait être dans deux DataContracts différents.
Pour C # c'est bien. Le service Web est bien créé. Un programme C # peut facilement créer un WSDL et tout va bien.
Essayez maintenant de créer un WSDL avec VB (n’importe quelle version). Le message "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 du langage VB. Mais!!!
Utilisez FxCOP et analysez le code C # d'origine. FxCOP indique que l'utilisation d'email/Email est un problème. Recommande d'utiliser un nom différent prenant en charge l'insensibilité à la casse. Notez également que, à ce jour, le framework .NET compte 106 langages de programmation et que de nombreux langages ont la sensibilité à la casse ON. Nous nous dirigeons tous vers le cloud et souhaitons que nos services soient accessibles à toutes les plateformes et tous les langages de programmation.
Votre choix est donc de rester sensible à la casse dans votre programme et si vous êtes un gars C, vous le voudriez. Si le programme doit être utilisé/utilisé 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_.NEThttp://www.vbrad.com/article.aspx?id=65
VB.NET est sensible à 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
Ces tout le code jettera un COMPILE-TIME ERROR .
Pour le premier exemple, une erreur apparaîtra, indiquant que "La variable locale 'A' est déjà déclarée dans le bloc actuel".
Alors que pour les 2ème et 3ème exemples, une erreur sera affichée en indiquant que "'Public Sub b ()' a plusieurs définitions avec des signatures identiques". et "'Fonction publique c() en tant qu'entier' 'a plusieurs définitions avec des signatures identiques.", respectivement.
De ces erreurs, notez que les erreurs sont renvoyées à des positions différentes pour les variables et les procédures/fonctions. Pour les variables, une erreur est générée à la 2ème déclaration, tandis que pour les procédures/fonctions, elle est générée à la 1ère déclaration/définition du code identique.
Comme l'a dit un utilisateur dans un commentaire quelque part ci-dessus, le code VB.NET est vérifié et/ou corrigé en permanence en arrière-plan; vous pouvez voir cette erreur dans la fenêtre "Liste des erreurs" dans VS IDE. Et comme ceci est une erreur et pas un avertissement , le code ne sera pas compilé tant que l'erreur n'est pas résolue.
Le masquage de symboles (par exemple, le champ de masquage local) est également insensible à la casse.
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
La sortie du compilateur VB.NET est décompilée (et donc équivalente) au C # suivant:
public class C
{
public string Name;
public bool M(string name)
{
return string.Equals(name, name); // both lowercase
}
}
string.Equals est passé le champ deux fois. Le local est caché, quel que soit le cas. Le langage est insensible à la casse.
Pour référencer explicitement un membre, tel que ce champ, vous devez déréférencer le membre via Me:
Return String.Equals(name, Me.Name) ' differentiate field from local
Je n'ai jamais vu personne commenter votre 2e question explicite à la fin: "2: est-ce assez convaincant pour que je pense à 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 d'options que C # laisse le programmeur choisir de limiter ses options. Je préfère fortement le C #, mais pour la seule sensibilité à la casse, je ne pense même pas que c'est proche de l'apprentissage d'une langue simplement parce qu'elle est sensible à la casse. toutes les fonctionnalités sont importantes, 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, parce que j'ai une préférence, mais je vais aussi être honnête sur les inconvénients de C #.
tout d'abord, les deux langues ont des avantages et des inconvénients. les différences que vous pouvez faire dans une langue et qui ne peuvent pas être faites dans l'autre 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.
quand 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 au fil des ans, j'ai constaté que de nombreuses fonctionnalités qui ne sont pas dans une langue sont ajoutées à une 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 .. de nombreuses manières! J'ai même vu de la bêtise parler lorsque l'affirmation opposée est faite, que VB enregistre la dactylographie. mais s'il vous plaît écoutez les gens qui vous disent utiliser les deux langues, et ils ne l'utilisent pas rarement. J'utilise à la fois C # et VB, C # à la maison parce que je l'aime (et quand je travaille avec C # au travail), et mes demandes de travail plus récentes que j'utilise VB et non C #. je consomme donc plus souvent VB maintenant (depuis environ 10 mois maintenant), mais dans mon témoignage personnel, je préfère de loin le C # et, en ce qui concerne la frappe, VB est considérablement plus de frappe. Le seul exemple que j'ai lu où quelqu'un essayait réellement de dire VB était plus concis, donnait un exemple 'avec ...' avec une variable longue dans le avec, de sorte qu'en VB, vous pouvez simplement utiliser '.propriété'. c’est stupide de prétendre que VB nécessite moins de dactylographie. il y a quelques petites choses (et pas seulement cet exemple) où VB est plus court, mais beaucoup plus souvent quand C # est plus concis, dans la pratique.
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 communes. en C #, il n'y a pas de mot "alors" à taper! :) toutes les instructions 'end ...' prennent également la saisie en c #, qui n'est généralement qu'une accolade fermante '}'. J'ai lu que certaines personnes affirment que plus de 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 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 programmeur, car la révision de code suivante pourrait être mieux conçue. cela s'applique aux 'nombreuses accolades de fermeture déroutantes en C #' plus si les blocs imbriqués sont du même type que plusieurs IF imbriqués, alors VB souffre du même problème que celui en C #. ce n'est pas un avantage en VB. C’est précisément pour cette raison que j’aimerais commenter le symbole ou la déclaration de clôture dans les deux langues. oui, c'est plus verbeux à faire, mais dans les deux langues, vous avez la possibilité d'être clair, ce qui est important dans les cas spécifiques, fondés sur le jugement. Je pense que la clarté du code est assez importante.
2: VB n'a pas de commentaire multiligne. quand je travaillais avec VB cela ne me dérangeait pas. puis je suis allé à quelques langues de style C. Maintenant, je suis de retour principalement avec VB.NET au travail et je les manque. c'est simplement quelque chose que vous trouvez pratique et que vous devez ensuite perdre. :(
3: Les expressions "andalso" et "orelse" de VB sont plutôt ennuyeuses si vous tapez tout cela alors qu'en C #, elles sont simplement "&&" et "||". encore une fois, moins de frappe. ce n'est pas rare dans mon code dans 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" en VB, il produit un code moins optimal pour quelqu'un qui aime la clarté du code. "Or" 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'enrouler sur la ligne suivante, je déteste le réajustement "contrôle" de VB.NET de mon code. C # le fait un peu, mais je le trouve plus utile en C #, où en VB, il est beaucoup plus contrôlable. mais il s’agit plus de VB.NET IDE que de C # IDE plutôt que du langage lui-même. mais je ne sais pas si vous voulez les deux ou uniquement les fonctionnalités du langage sans IDE différences.
5: une qui me manque vraiment est juste 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 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 avec '}'. VB n'a pas cette fonctionnalité, mais sa correspondance la plus proche est un bloc inconditionnel 'If True Then' et 'End If'. (Notez encore l'équivalent VB.NET à 2 caractères C # vs 18 caractères ... plus de frappe en VB.)
6: Opérateurs auto-incrémentés et décrémentés: ++ et - comme dans myVariable++ ou ++myVariable ou les versions de décrémentation équivalentes. cela est très utile ... parfois. Voici un exemple de code réel où 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 très bon exemple où les 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 à leur langage humain. Et c'est très bien. Les préférences sont bien. Pour moi, l’effort à la main est un facteur que j’évalue, et je pense que tout le monde peut s’habituer à penser selon les symboles qu’il préfère, car "if" et "then" sont des symboles d’un alphabet, et C "," if (condition) statement; " la syntaxe sont aussi des symboles. l'un est plus proche de la syntaxe d'un non-programmeur que l'autre. je préfère le concis.
Je pense aussi qu'avoir besoin d'utiliser 'c' après les littéraux de caractère dans VB pour en faire un littéral de caractère plutôt qu'une chaîne est ennuyeux. J'aime la concision de C # avec beaucoup plus. lorsqu'une méthode nécessite un littéral de caractère, vous devez fournir un caractère et non une chaîne de caractères, vous êtes donc parfois obligé d'utiliser ":"c dans VB alors que dans C #, il s'agit de ':'. Je pense que c'est la cueillette tho.
Pour être juste, je dirai qu'il y a des avantages que j'aime bien à VB comme ne pas avoir à mettre des parenthèses vides après les appels de méthode, comme Dim nameUpper$ = name.ToUpperInvariant où C # requiert les parenthèses vides: string nameUpper = name.ToUpperInvariant(). ou doublez cela comme le couper aussi: 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 l'atténuer '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, je l'utilise donc 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, ceci est mon "témoignage" de programmation de C # par rapport à VB. les deux sont de belles langues tho, à mon avis. mais oui, je préfère encore beaucoup C #.
p.s. Comme je prévois de programmer pour la plus grande partie de ma vie, j’ai même réappris à taper à l’aide du clavier le plus efficace: le clavier Dvorak, qui demande environ le tiers de l’effort nécessaire pour taper en anglais par rapport à un clavier Qwerty. le chercher. vous voudrez peut-être aussi changer. ;) ma saisie a été facilitée à 67%! :) J'encourage quiconque à sortir des sentiers battus et à évaluer une meilleure efficacité de votre travail. La disposition du clavier simplifié Dvorak et C # l’ont fait pour moi. :)
P.S.S. Je comparerais le Dvorak et le C # à la métrique, par opposition à la disposition du clavier Qwerty et à la VB aux mesures empiriques. Dvorak, métrique et C # sont simplement "propres". MAIS VB n'est pas très loin derrière. Mais il souffre de la nécessité d’une compatibilité ascendante avec l’ancien code VB6 et le code pré .NET, comme le "Or" ou "OrElse", et "IIF ()".
Je termine avec une mise en garde. S'il vous plaît soyez plus prudent que d'écouter les gens qui ne savent pas vraiment de quoi ils parlent. La moitié de tous les inconvénients contre VB et C # ne sont plus un problème pas, et les gens postent encore qu'ils ignoraient quels inconvénients existaient encore dans la langue. Le meilleur exemple que je puisse imaginer est celui des commentaires XML pour les méthodes utilisant la triple apostrophe dans VB ou les symboles de commentaire à triple barre oblique en C #. Mais s'il vous plaît, discernez par vous-même si une personne parle d'ignorance ou d'expérience. Le témoignage personnel signifie qu'ils savent de leur expérience réelle. Et après que quelqu'un a beaucoup d'expérience, redressez l'oreille. J'ai plus de 10 ans d'expérience à la fois en C # et en VB. Et cela se résume à ceci: les deux langues sont (très) bonnes. Et la plupart des différences, vous pouvez voir immédiatement dans les 5 minutes de lecture du code. Mais oui, d'autres caractéristiques peuvent prendre des années avant de trouver un handicap. Et un handicap dont je suis conscient (en C #), je ne peux même pas penser à une situation de la vie réelle où cela serait utile. Alors peut-être que ce n'est pas un handicap après tout.
Bonne codage!