Ist VB wirklich unabhängig von Groß- und Kleinschreibung?

Ich versuche hier nicht, ein Argument zu beginnen, aber aus irgendeinem Grund wird normalerweise angegeben, dass Visual Basic nicht zwischen Groß- und Kleinschreibung unterscheidet und C-Sprachen nicht (und irgendwie ist das eine gute Sache).

Aber hier ist meine Frage: Wo genau unterscheidet Visual Basic die Groß- und Kleinschreibung nicht? Wenn ich tippe ...

Dim ss As String
Dim SS As String

... in der Visual Studio 2008- oder Visual Studio 2010- IDE wird in der zweiten ID die Warnung " Lokale Variable SSist bereits im aktuellen Block deklariert " angezeigt . In der VBA VBE wird ein Fehler nicht sofort ausgelöst, sondern nur automatisch korrigiert.

Vermisse ich hier etwas mit diesem Argument, dass Visual Basic nicht zwischen Groß- und Kleinschreibung unterscheidet? (Auch wenn Sie wissen oder antworten möchten, warum wäre das eine schlechte Sache?)

Warum stelle ich diese Frage überhaupt?

Ich habe Visual Basic seit Jahren in vielen seiner Dialekte verwendet, manchmal als Hobbyist, manchmal für Programme für kleine Unternehmen in einer Arbeitsgruppe. In den letzten sechs Monaten habe ich an einem großen Projekt gearbeitet, viel größer als ich erwartet hatte. Ein Großteil des Beispielquellcodes befindet sich in C #. Ich habe keine brennende Lust, C # zu lernen, aber wenn es Dinge gibt, die ich bei den C # -Angeboten verpasse, die Visual Basic nicht bietet (ein Gegenteil wäre, dass VB.NET XML-Literale anbietet ), dann würde ich gerne um mehr über diese Funktion zu erfahren. In diesem Fall wird häufig argumentiert, dass bei C-Sprachen zwischen Groß- und Kleinschreibung unterschieden wird, und das ist gut, und Visual Basic unterscheidet nicht zwischen Groß- und Kleinschreibung und das ist schlecht. Ich würde gerne wissen...

1. Wie genau unterscheidet Visual Basic zwischen Groß- und Kleinschreibung, da bei jedem einzelnen Beispiel im Code-Editor zwischen Groß- und Kleinschreibung unterschieden wird (was bedeutet, dass der Fall korrigiert wird), ob ich es möchte oder nicht.
2. Ist dies zwingend genug für mich, um über einen Wechsel zu C # nachzudenken, wenn der Fall VB.NET irgendwie einschränkt, was ich mit Code tun kann?

Der Unterschied zwischen VBA und VB.NET besteht nur darin, dass VB.NET kontinuierlich im Hintergrund kompiliert wird. Beim Kompilieren des VBA wird eine Fehlermeldung angezeigt.

Wie Jonathan sagt , kann man sich beim Programmieren VB.NET als unabhängig von Groß- und Kleinschreibung vorstellen, abgesehen von Zeichenfolgenvergleichen, XML und einigen anderen Situationen ...

Ich denke, Sie interessieren sich für das, was sich unter der Haube befindet. Nun, bei der .NET Common Language Runtime wird zwischen Groß- und Kleinschreibung unterschieden , und VB.NET-Code hängt von der Laufzeit ab, sodass Sie sehen können, dass zur Laufzeit zwischen Groß- und Kleinschreibung unterschieden werden muss, z. B. wenn nach Variablen und Methoden gesucht wird.

Mit dem VB.NET-Compiler und -Editor können Sie dies ignorieren, da sie den Fall in Ihrem Code korrigieren .

Wenn Sie mit dynamischen Funktionen oder einer späten Bindung (Option Strict Off) herumspielen, können Sie nachweisen, dass bei der zugrunde liegenden Laufzeit zwischen Groß- und Kleinschreibung unterschieden wird. Eine andere Möglichkeit, dies zu erkennen, besteht darin, zu erkennen, dass Sprachen mit Groß- und Kleinschreibung wie C # dieselbe Laufzeit verwenden, sodass die Laufzeit offensichtlich die Groß- und Kleinschreibung unterstützt.

BEARBEITEN Wenn Sie die IDE aus der Gleichung entfernen möchten, können Sie jederzeit über die Befehlszeile kompilieren . Bearbeiten Sie Ihren Code in den Editor so hat es ssund SSsehen , was der Compiler tut.

EDIT Zitat von Jeffrey Richter in den .NET Framework Design Guidelines Seite 45.

Um klar zu sein, unterscheidet die CLR tatsächlich zwischen Groß- und Kleinschreibung. Bei einigen Programmiersprachen wie Visual Basic wird die Groß- und Kleinschreibung nicht berücksichtigt. Wenn der Visual Basic-Compiler versucht, einen Methodenaufruf in einen Typ aufzulösen, der in einer Sprache mit Groß- und Kleinschreibung wie C # definiert ist, ermittelt der Compiler (nicht die CLR) den tatsächlichen Fall des Methodennamens und bettet ihn in Metadaten ein. Die CLR weiß nichts darüber. Wenn Sie jetzt Reflection zum Binden an eine Methode verwenden, bieten die Reflection-APIs die Möglichkeit, Suchvorgänge ohne Berücksichtigung der Groß- und Kleinschreibung durchzuführen. Dies ist das Ausmaß, in dem die CLR Groß- und Kleinschreibung nicht berücksichtigt.

Ein Teil des Problems besteht darin, dass Sie die Sprache von der IDE-Erfahrung trennen müssen.

Als Sprache unterscheidet VB.NET in Bezug auf Bezeichner sicherlich nicht zwischen Groß- und Kleinschreibung. Aufruf DateTime.Parseund datetime.parsewird an genau den gleichen Code gebunden. Und im Gegensatz zu Sprachen wie C # ist es nicht möglich, Methoden oder Typen zu definieren, die sich nur von Fall zu Fall unterscheiden.

Als IDE versucht VB.NET, den Fall vorhandener Bezeichner beizubehalten, wenn ein Codeblock hübsch aufgelistet wird. Hübsche Listen treten immer dann auf, wenn Sie die aktuelle logische Codezeile verlassen. In diesem Fall verlassen Sie die zweite Deklaration von SS, der hübsche Lister bemerkt, dass eine Kennung mit diesem Namen vorhanden ist, und korrigiert sie, um eine übereinstimmende Groß- / Kleinschreibung zu erhalten.

Dieses Verhalten wird jedoch nur als Benutzer-Mehrwert durchgeführt. Es ist kein Teil der Kernsprache.

VB unterscheidet meistens nicht zwischen Groß- und Kleinschreibung, es gibt jedoch Ausnahmen. Bei XML-Literalen und -Verständnis wird beispielsweise zwischen Groß- und Kleinschreibung unterschieden. Bei String-Vergleichen wird normalerweise zwischen Groß- und Kleinschreibung unterschieden, im Gegensatz zu T-SQL. Es gibt jedoch einen Compiler-Schalter, mit dem bei String-Vergleichen die Groß- und Kleinschreibung nicht berücksichtigt wird. Und natürlich gibt es die Randfälle beim Umgang mit Vererbung, COM und dynamischer Sprachlaufzeit.

Ja, der VB.NET-Compiler behandelt Bezeichner ohne Berücksichtigung der Groß- und Kleinschreibung. Und ja, das kann Probleme verursachen, wenn Assemblys verwendet werden, die in einer anderen Sprache geschrieben wurden oder COM-Komponenten verwenden. Der erstere Fall wird durch die Common Language Specification abgedeckt . Die relevante Regel lautet:

Damit zwei Bezeichner als unterschiedlich betrachtet werden können, müssen sie sich nicht nur durch ihren Fall unterscheiden.

Der COM-Fall wird vom Typbibliotheks-Builder ziemlich grob behandelt, er erzwingt, dass das Gehäuse von Bezeichnern mit demselben Namen identisch ist. Auch wenn diese Bezeichner unterschiedliche Rollen haben. Mit anderen Worten, ein Methodenparameter mit dem Namen "Index" erzwingt, dass ein Methodenname "Index" in "Index" umgewandelt wird. Das hat ziemlich viel Kopfkratzen verursacht, wie Sie sich vorstellen können :)

VB bewahrt die Groß- und Kleinschreibung (in der IDE), unterscheidet jedoch nicht zwischen Groß- und Kleinschreibung . In gewisser Weise ist es wie ein Windows-Dateisystem. Hello.txt und hello.txt gelten als der gleiche Dateiname.

Die IDE geht davon aus, dass die Deklaration einer Variablen der "richtige" Fall für diese Variable ist, und passt jede Instanz dieser Variablen an die Deklaration an. Dies geschieht aus Gründen der Aufmerksamkeit und der Konsistenz, jedoch nicht aus Gründen der Funktionalität.

Ich habe mehrere Fälle gesehen, in denen der Fall nicht automatisch geändert wurde, um mit der Deklaration übereinzustimmen, und die Anweisung funktioniert genauso. Sie können auch einen beliebigen Texteditor verwenden, um Code zu schreiben, der in verschiedenen Fällen problemlos kompiliert werden kann.

Eine Randnotiz:

Die meisten Menschen denken ohne Berücksichtigung der Groß- und Kleinschreibung. Wenn wir das Wort "Hund" sehen, wird das Wort in unseren Gedanken in Bedeutung übersetzt. Die Bedeutung des Wortes basiert nicht auf der Groß- und Kleinschreibung (dh unabhängig davon, ob der Spruch "DOG", "DoG" oder "dOG" noch bellt). COMPUTER sehen Wörter als diskrete Beutel mit Bits. Groß- und Kleinbuchstaben sind unterschiedliche Bitmuster und daher unterschiedlich.

Da die meisten Programmierer Menschen sind, scheint die Groß- und Kleinschreibung eher an die Denkweise der Menschen angepasst zu sein, und bei der Groß- und Kleinschreibung geht es eher darum, wie Menschen ihre Denkweise an die Einschränkungen einer Maschine anpassen.

Dies ist Teil des von Ihnen verwendeten Editors. Sie verhalten sich möglicherweise anders, aber bei Visual Basic wird die Groß- und Kleinschreibung nicht berücksichtigt. Also ssund SSsind gleich.

Weitere Informationen finden Sie im Tutorial zu VB.NET Basics :)

Ich bin nicht sicher, ob ich dich verstehe? VB unterscheidet nicht zwischen Groß- und Kleinschreibung, daher sind ss und SS dieselbe Variable. Der Compiler beschwert sich daher korrekt, dass Sie die Variable erneut deklariert haben.

Ich denke, dass Variablen nicht zwischen Groß- und Kleinschreibung unterscheiden, Funktionsnamen jedoch.

Ja, bei VB wird die Groß- und Kleinschreibung nicht berücksichtigt. Es wirft manchmal diejenigen, die nicht daran gewöhnt sind, für eine kleine Schleife.

In VB.NET muss man sich nicht allzu sehr anstrengen, um Code mit unterschiedlichen Groß- / Kleinbuchstaben eines Bezeichners zu erstellen. Wenn Sie das Gehäuse eines Bezeichners in der Datei ändern, in der er ohne Verwendung der Funktion "Umbenennen" deklariert wurde, wird der Name in anderen Dateien nicht aktualisiert. Wenn Sie jedoch eine Zeile bearbeiten, die den Namen enthält, entspricht er der aktuellen Definition.

Auf diese Weise kann festgestellt werden, dass bei VB.NET die Groß- und Kleinschreibung größtenteils nicht berücksichtigt wird, der CLR jedoch der Fall von Bezeichnern zur Verfügung gestellt wird, die diese Informationen möglicherweise auf Groß- und Kleinschreibung verwenden.

Ich kann dies nur anbieten, was, wie ich mich aus meinen Programmierlehrbüchern in den frühen 80er Jahren erinnere, darin besteht, dass senstive Sprachen (zu dieser Zeit) ausschließlich dazu gedacht waren, Fehler bei der Kompilierung zu reduzieren. Das heißt, die "Strenge" sollte eine Codierungsdisziplin mit größerer Genauigkeit entwickeln. Wie sich herausgestellt hat, hat sich auch die Hinzufügung einer korrekten Kennzeichnung von Variablen, Klassen, Methoden, Funktionen und allem, was Sie sonst noch hineinwerfen möchten, weiterentwickelt.

Ich erinnere mich, dass fast alle dieser Bücher ein empfohlenes Muster für führende Groß- und Kleinschreibung, Kleinbuchstaben usw. enthielten. Wie wir alle wissen, wurde ein Großteil davon weggeworfen oder sollte ich sagen, in der Praxis ignoriert, abgesehen von den High-End-Produktionshäusern und CASE-Lösungen oder für diejenigen, die ein höheres Qualifikationsniveau erreicht haben. Ich denke, jeder erlebt diese Lernkurve.

Angesichts der Weiterentwicklung dieser Sprachen und IDEs stellt sich die bessere Frage, welche Sprache meine Entwicklungszeit verbessert. Wenn Sie nicht mit den verschiedenen langs vertraut sind, sind Ihre Möglichkeiten natürlich begrenzt.

Ich werde versuchen, Ihre zweite Frage zu beantworten.

"Ist dies zwingend genug für mich, um über einen Wechsel zu C # nachzudenken, wenn der Fall VB.NET irgendwie einschränkt, was ich mit Code tun kann?"

Erstellen Sie einen WCF-Webdienst mit C #. Erstellen Sie einen DataContract (1 Klasse). Eine mit der Eigenschaft "Zeichenfolge E-Mail". Eine andere mit "string Email" als einer anderen Eigenschaft. Ihre Wahl, um als persönliche E-Mail oder Büro-E-Mail zu verstehen. Oder es könnte in zwei verschiedenen DataContracts sein.

Für C # ist das in Ordnung. Der Webdienst wird einwandfrei erstellt. Das AC # -Programm kann leicht eine WSDL erstellen und alles ist in Ordnung.

Versuchen Sie nun, eine WSDL mit VB (eine beliebige Version) zu erstellen. Es wird angezeigt, dass "E-Mail" bereits deklariert ist und die WSDL-Generierung fehlschlägt.

Wie jeder andere habe ich angenommen, dass dies ein Nachteil in der VB-Sprache ist. Aber!!!

Verwenden Sie FxCOP und analysieren Sie den ursprünglichen C # -Code. Laut FxCOP ist die Verwendung von E-Mail / E-Mail ein Problem. Empfiehlt die Verwendung eines anderen Namens, der die Groß- und Kleinschreibung nicht unterstützt. Beachten Sie auch, dass .NET Framework derzeit 106 Programmiersprachen hat und es viele Sprachen gibt, bei denen die Groß- und Kleinschreibung eingeschaltet ist. Wir bewegen uns alle in Richtung Cloud und möchten, dass unsere Dienste für alle Programmierplattformen / -sprachen zugänglich sind.

Wenn Sie also ein C-Typ sind, ist es Ihre Wahl, wenn Sie zwischen Groß- und Kleinschreibung unterscheiden. Wenn das Programm von anderen Nicht-C-Programmen verwendet werden soll, müssen Sie die Groß- und Kleinschreibung nicht berücksichtigen, aber Ihre Sprache ist Ihre Wahl.

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

Das Ausblenden von Symbolen (z. B. lokales Ausblendfeld) unterscheidet ebenfalls nicht zwischen Groß- und Kleinschreibung.

Hier ist ein Beispiel :

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

Die Ausgabe des VB.NET-Compilers wird in das folgende C # dekompiliert (und entspricht diesem):

public class C
{
    public string Name;

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

string.Equalswird das Feld zweimal übergeben. Das Lokal ist versteckt, unabhängig vom Fall. Die Sprache unterscheidet nicht zwischen Groß- und Kleinschreibung.

Um explizit auf ein Mitglied wie dieses Feld zu verweisen, müssen Sie das Mitglied über Folgendes dereferenzieren Me:

Return String.Equals(name, Me.Name) ' differentiate field from local

Ich habe am Ende noch keinen Kommentar zu Ihrer expliziten zweiten Frage gesehen: "2: Ist dies zwingend genug, um über einen Wechsel zu C # nachzudenken, wenn der Fall VB.NET die Möglichkeiten, die ich mit Code habe, irgendwie einschränkt?"

Ich bevorzuge den Ansatz mit mehr Optionen, bei dem C # dem Programmierer die Wahl lässt, ob er die Optionen des Programmierers einschränkt. Ich bevorzuge C # sehr, aber allein für die Groß- und Kleinschreibung würde ich nicht einmal denken, dass es dem Erlernen einer Sprache nahe kommt, nur weil es die Groß- und Kleinschreibung berücksichtigt. Alle Funktionen sind wichtig, und wenn ich mir die Vorteile von C # und VB.NET anschaue, bevorzuge ich C #. Aber ich werde Ihnen eine wirklich ausgewogene Perspektive geben, voreingenommen ja, weil ich eine Präferenz habe, aber ich werde auch ehrlich über die Nachteile von C # sein.

Zunächst einmal haben beide Sprachen Vor- und Nachteile. Die Unterschiede, die Sie in einer Sprache machen können, die in der anderen nicht möglich sind, nehmen ab, da Microsoft zum Glück beide Sprachen verbessert und sie offenbar keine unfaire Parteilichkeit gegenüber beiden Sprachen zeigen.

Als C # zum ersten Mal herauskam, hatte VB keine XML-Kommentare, die man vor Methoden stellen konnte, die ich in C # geliebt habe. Ich hasste das in VB.NET. Aber ich habe im Laufe der Jahre gesehen, dass viele Funktionen, die nicht in einer Sprache verfügbar sind, zur anderen hinzugefügt werden. (Das gleiche Team von MS-Entwicklern entwickelt sowohl C # als auch VB. Daher ist es sinnvoll, dass die Funktionen ziemlich ähnlich werden.)

aber Sie haben gefragt, was C # hat, was VB nicht hat. Hier sind einige, an die ich sofort denken kann:

1: C # ist prägnanter und erfordert weniger Eingabe .. auf VIELE Arten! Ich habe sogar Dummheit gesehen, als die gegenteilige Behauptung aufgestellt wurde, dass VB das Tippen spart. Aber bitte hören Sie den Leuten zu, die Ihnen sagen, dass sie beide Sprachen verwenden, und keine wird von ihnen selten verwendet. Ich benutze sowohl C # als auchVB, C # zu Hause, weil es mir gefällt (und wenn ich bei der Arbeit mit C # arbeite), und meine neueren Jobanfragen, dass ich VB und nicht C # verwende. Daher benutze ich VB jetzt häufiger (seit ungefähr 10 Monaten), aber in meinem persönlichen Zeugnis bevorzuge ich C # sehr, und in Bezug auf die tatsächliche Eingabe ist VB wesentlich häufiger. Das einzige Beispiel, das ich gelesen habe, in dem jemand tatsächlich versucht hat zu sagen, dass VB prägnanter ist, war ein 'with ...'-Beispiel mit einer langen Variablen im with, sodass Sie in VB einfach' .property 'verwenden können. Dies ist eine Dummheit in der Behauptung, dass VB weniger Tippen benötigt. Es gibt einige Dinge (und nicht nur dieses Beispiel), bei denen VB kürzer ist, aber in der Praxis viel häufiger, wenn C # prägnanter ist.

Aber der Hauptgrund, warum ich glaube, dass C # prägnanter ist, sind die ausführlichen "IF / THEN" -Anweisungen von VB. wenn Aussagen häufig sind. In C # gibt es kein "Dann" -Wort zum Eingeben! :) Auch alle 'end ...' - Anweisungen müssen eingegeben werden, was in c # normalerweise nur eine schließende Klammer '}' ist. Ich habe gelesen, dass einige Leute behaupten, dass diese Ausführlichkeit in VB.NET ein Vorteil für VB ist, da mehrere schließende Blockanweisungen / Symbole verschachtelt werden können und unmittelbar nebeneinander enden, aber ich bin völlig anderer Meinung. Eine Person kann fast immer ein Programm besser in C # oder VB schreiben als ein anderer Programmierer, da die nächste Code-Revision besser gestaltet werden könnte. Dies gilt für die 'Verwirrung zahlreicher schließender Klammern in C #'. Wenn die verschachtelten Blöcke alle vom gleichen Typ sind wie mehrere verschachtelte IFs, hat VB das gleiche Problem wie in C #. Dies ist in VB kein Vorteil. Genau in dieser Situation möchte ich kommentieren, was mein Schlusssymbol oder meine Schlusserklärung in beiden Sprachen beinhaltet. Ja, dies ist ausführlicher, aber in beiden Sprachen haben Sie die Möglichkeit, klar zu sein, was in urteilsbasierten, situationsspezifischen Fällen wichtig ist. Ich denke, Code Klarheit ist sehr wichtig.

2: VB hat keine mehrzeiligen Kommentare. Als ich mit VB gearbeitet habe, hatte ich nichts dagegen. dann ging ich zu ein paar Sprachen im C-Stil. Jetzt bin ich zurück und benutze hauptsächlich VB.NET bei der Arbeit. Ich vermisse sie. Es ist nur etwas, das Sie bequem finden und dann verlieren müssen. :((

3: VBs 'andalso' und 'orelse' sind ziemlich ärgerlich, wenn man in C # einfach '&&' und '||' schreibt. wieder weniger tippen. Dies ist in meinem Code sowohl in VB als auch in C # nicht selten. Wenn für die Funktionalität 'OR' vs 'OrElse' normalerweise keine Rolle spielt, außer dass 'OrElse' für den Computer schneller ist. Wenn ein Programmierer also nur 'Or' und 'And' in VB verwendet, erzeugt er weniger optimalen Code für Jemand, der Klarheit des Codes mag. 'Or' ist viel einfacher zu überfliegen als 'OrElse'.

4: Mehr Flexibilität bei der Code-Platzierung in C #. Wenn eine Zeile lang ist und Sie sie in die nächste Zeile einschließen möchten, hasse ich es, wenn VB.NET meinen Code "kontrolliert". C # macht es ein wenig, aber ich finde es nützlicher in C #, wo es in VB viel kontrollierender ist. Dies ist jedoch eher die VB.NET-IDE als die C # -IDE als die Sprache selbst. aber ich weiß nicht, ob Sie beide oder nur die Sprachfunktionen ohne IDE-Unterschiede wollen.

5: Eine, die ich wirklich vermisse, ist das Erstellen eines neuen Codeblocks in C #. In einer Methode passiert möglicherweise viel, und ich möchte eine Variable in einem sehr kleinen Codeblock deklarieren, aber diese Variable nicht außerhalb dieses Blocks deklarieren die gesamte Methode. In C # können wir einfach einen neuen Block mit '{' erstellen und ihn mit '}' beenden. VB hat keine solche Funktion, aber die engste Übereinstimmung besteht aus einem bedingungslosen Block "If True Then" und "End If". (Beachten Sie erneut das 2-stellige C # gegenüber dem 18-stelligen VB.NET-Äquivalent ... mehr Eingabe in VB.)

6: Selbstinkrementierungs- und Dekrementierungsoperatoren: ++ und - wie in myVariable++oder ++myVariableoder den entsprechenden Dekrementierungsversionen. das ist sehr praktisch ... manchmal. Hier ist ein Beispiel für tatsächlichen Code, als ich C # sehr vermisst habe:

// 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

Und um ein SEHR gutes Beispiel zu geben, in dem C # regiert, ist dies mehr Code, den ich kürzlich persönlich geschrieben habe:

// 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

Vielleicht ist dies ein ausreichender Beweis dafür, dass C # prägnanter ist. Aber nicht alle Programmierer mögen Prägnanz. Einige lesen lieber "wenn a <b dann ...", weil es für ihre menschliche Sprache natürlicher ist. Und das ist gut so. Einstellungen sind in Ordnung. Für mich ist Handarbeit ein Faktor, den ich schätze, und ich denke, jeder kann sich daran gewöhnen, in beliebigen Symbolen zu denken, die er bevorzugt, denn "wenn" und "dann" sind Symbole eines Alphabets und C # 's "if (Bedingung) -Anweisung"; Syntax sind auch Symbole. Einer ist der Syntax eines Nicht-Programmierers näher als der andere. Ich bevorzuge die prägnante.

Ich denke auch, dass es ärgerlich ist, 'c' nach Zeichenliteralen in VB zu verwenden, um es zu einem Zeichenliteral und nicht zu einer Zeichenfolge zu machen. Ich mag die Prägnanz von C # viel mehr. Wenn für eine Methode ein Zeichenliteral erforderlich ist, müssen Sie ein Zeichen und keine Zeichenfolge mit einer Zeichenlänge angeben. Daher müssen Sie manchmal ":"cin VB verwenden, während dies in C # der Fall ist ':'. Ich denke, das ist kein Problem.

Um fair zu sein, werde ich sagen, dass es für VB Vorteile gibt, wie zum Beispiel, dass ich nach Methodenaufrufen keine leeren Klammern setzen muss, z. B. Dim nameUpper$ = name.ToUpperInvariantwenn C # die leeren Klammern benötigt : string nameUpper = name.ToUpperInvariant(). oder doppelt so hoch wie es zu Besatz: Dim nameUpper$ = name.Trim.ToUpperInvariantvs string nameUpper = name.Trim().ToUpperInvariant(). Ich mag VBs prägnante Verwendung dessen, wie ich es $oben verwendet habe, um es als Zeichenfolge zu dimmen, wobei C # diese Verknüpfungen nicht hat. VB hat diese Verknüpfungen für die Typen String, Integer, Long, Decimal, Single und Double, aber der Nachteil ist, dass sie weniger klar sind, daher verwende ich sie mit Vorsicht. Trotzdem bevorzuge ich prägnanten Code.

Nun, das sind nur ein paar Gedanken von diesem erfahrenen Programmierer, und wenn ich bedenke, ist dies mein Programmierzeugnis von C # gegen VB. beide sind meiner meinung nach nette sprachen. aber ja, ich bevorzuge immer noch C #.

ps Da ich vorhabe, den größten Teil meines Lebens zu programmieren, habe ich sogar wieder gelernt, mit der effizientesten Tastatur zu tippen: der Dvorak-Tastatur, die etwa 1/3 des Aufwandes für die Eingabe von Englisch erfordert als mit einer QWERTY-Tastatur. Schlag es nach. Vielleicht möchten Sie auch wechseln. ;) es hat mir das Tippen um 67% erleichtert! :) Ich ermutige jeden, über den Tellerrand hinaus zu denken und eine bessere Effizienz Ihrer Arbeit zu bewerten. Das Dvorak Simplified Keyboard Layout und C # haben dies für mich getan. :) :)

PSS Ich würde Dvorak und C # mit Metrik vergleichen, im Gegensatz zum QWERTY-Tastaturlayout und VB mit den empirischen Messungen. Dvorak, Metrik und C # sind nur "sauber". ABER VB ist nicht wirklich weit dahinter. Es muss jedoch abwärtskompatibel zu altem VB6-Code und Pre-.NET-Code sein, wie z. B. 'Or' vs 'OrElse' und 'IIF ()'.

Ich beende mit Vorsicht. Seien Sie bitte vorsichtiger, als Menschen zuzuhören, die nicht wirklich wissen, wovon sie sprechen. Die Hälfte aller Nachteile gegen VB und C # sind es nichtEs gibt immer noch Probleme, und die Leute schreiben immer noch, dass sie nicht wissen, welche Nachteile es in der Sprache wirklich noch gibt. Das beste Beispiel, das ich mir vorstellen kann, sind XML-Kommentare für Methoden, die dreifaches Apostroph in VB oder dreifache Schrägstrich-Kommentarsymbole in C # verwenden. Aber bitte erkennen Sie selbst, ob eine Person aus Unwissenheit oder aus Erfahrung spricht. Persönliches Zeugnis bedeutet, dass sie es aus ihrer realen Erfahrung wissen. Und wenn jemand viel Erfahrung damit hat, dann lege die Ohren auf. Ich habe mehr als 10 Jahre Erfahrung in C # und VB. Und es läuft darauf hinaus: Beide sind (sehr) gute Sprachen. Und die meisten Unterschiede können Sie sofort innerhalb von 5 Minuten nach dem Lesen des Codes sehen. Aber ja, bei anderen Merkmalen kann es Jahre dauern, bis ein Handicap gefunden wird. Und ein Handicap, das mir bekannt ist (in C #), kann ich ' Ich denke nicht einmal an eine reale Lebenssituation, in der es nützlich wäre. Vielleicht ist es doch kein Handicap.

Viel Spaß beim Codieren!

VB.NET unterscheidet nicht zwischen Groß- und Kleinschreibung.

Beispiele:

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

Dieser gesamte Code löst einen COMPILE-TIME ERROR aus .

Im ersten Beispiel wird der Fehler "Lokale Variable 'A' ist bereits im aktuellen Block deklariert" angezeigt.

Während für das 2. und 3. Beispiel der Fehler angezeigt wird, dass "'Public Sub b ()' mehrere Definitionen mit identischen Signaturen hat." und "'Public Function c () As Integer' hat mehrere Definitionen mit identischen Signaturen."

Beachten Sie bei diesen Fehlern, dass die Fehler für Variablen und Prozeduren / Funktionen an verschiedenen Positionen ausgelöst werden. Bei Variablen wird bei der 2. Deklaration ein Fehler ausgelöst, bei Prozeduren / Funktionen bei der 1. Deklaration / Definition des identischen Codes.

Wie von einem Benutzer in einem Kommentar irgendwo oben gesagt, wird der VB.NET-Code im Hintergrund kontinuierlich überprüft und / oder korrigiert. Sie können diesen Fehler im Fenster "Fehlerliste" in VS IDE sehen. Und da dies EIN FEHLER und KEINE WARNUNG ist , wird der Code erst kompiliert, wenn der Fehler behoben ist.