Option Strict On

  • VB.NET
  • .NET 4.5

Es gibt 24 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    Option Strict On

    Moin Leute,

    mal eine Frage an diejenigen hier, die andere ermutigen Option Strict On zu verwenden: Ich lese hier immer nur "Verwende bitte Option Strict On", aber ich habe bisher keine Begründung dafür in diesem Forum entdeckt. Ich programmiere zwar selber überwiegend strikt, aber ich komme auch aus dem C#-Sektor und bin nur aufgrund meiner Arbeitsstelle auf Visual Basic umgestiegen. Da gerade so Dinge wie late binding und ein gering strikter Programmierstil eigentlich der elementare Unterschied zwischen C# und Visual Basic sind, finde ich es etwas befremdlich das gerade in einem Visual Basic Forum ständig darauf aufmerksam gemacht wird. Die Frage vielleicht mal andersherum gestellt: Wenn sowieso alle mit Option Strict On programmieren sollen, welche Daseinsberechtigung hat Visual Basic dann überhaupt noch gegenüber C#? Es ist weniger compiler-nah, benötigt viel mehr Programmcode (auch wenn die Benamungen von Klassen und Schleifen in Visual Basic zugegebenermaßen sprechender sind) und zu allem übel werden Neuerungen insbesondere im Bereich von Web-Architecture und API-Programmierung vorzugsweise zuerst für C# entwickelt (vermutlich da die Syntax näher an Java Script ist) und dann mit enormer Verzögerung für Visual Basic nachgezogen (Siehe beispielsweise vorgefertigte Projektvorlage in Visual Studio 2019 für Azure-Architecture, ist meines Wissens nach bis heute nicht in Visual Basic übersetzt worden und falls doch definitiv nicht in die Standard Vorlagen übernommen worden). Warum genau sollte man also Visual Basic verwenden insbesondere mit Option Strict On? Ich habe ein wenig darüber nachgedacht und mir fällt kein plausibler Grund ein. Würde mich freuen, wenn von euch vielleicht jemand eine Idee dazu hat.


    Ein Computer wird das tun, was du programmierst - nicht das, was du willst.
    Damit man Typensicher unterwegs ist. Andernfalls versucht der Compiler „auf gut glück“ deine Daten zu Konvertieren... zudem vergisst man dann z.B. nicht bei ner Function Daten zurück zugeben. Option Strict On ist dein Bodyguard der dich vor dir selber schützt.

    VB ist eben schon lange am Markt. Das kann man halt nicht einfach anschalten. Die „alten“ VB6 Hasen kommen zudem wohl eher mit VB.Net als C# zurecht.
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen
    Ja ist ein guter Einwand. Aber dann richtet sich der Tipp meiner Meinung nach eher an Neulinge im Bereich VB als Erleichterung für die Arbeit. Mich würde es an einigen Stellen eher behindern, wenn ich überall auf implizite Konvertierungen verzichten würde.


    Ein Computer wird das tun, was du programmierst - nicht das, was du willst.

    Yanbel schrieb:

    Warum genau sollte man also Visual Basic verwenden

    Yanbel schrieb:

    Ich programmiere zwar selber überwiegend strikt, aber ich komme auch aus dem C#-Sektor und bin nur aufgrund meiner Arbeitsstelle auf Visual Basic umgestiegen
    -> frag mal Deinen Arbeitgeber, warum Du jetzt VB.NET nutzen sollst.
    Bzgl Late Binding mithilfe von Option Strict Off: da hatte ich neulich schon mal was geschrieben. Da kann man sagen: Wenn man sich darauf verlässt, dass man mit Late Binding im Vorteil ist, soll nicht rummeckern, wenn es erst zur Laufzeit zu Fehlern kommt, weil man eben doch nicht den Objekttyp vor sich hat, den man zur Designzeit vermutet. Wenn man aber durch Option Strict On schon zur Designzeit einen Typ festlegen muss, kann man auch - dank der IDE - nachschauen, welche Methoden, Eigenschaften, ... vom Objekttyp unterstützt/angeboten wird, und braucht keine Spekulatius zu backen und zu hoffen, dass schon alles gutgehen wird.

    ##########

    falschen Link gepostet. Das hier ist der, den ich gesucht hab: Link eben
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Häufig von mir verwendete Abkürzungen: CEs = control elements (Labels, Buttons, DGVs, ...) und tDS (typisiertes DataSet)
    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht in den Spekulatiusmodus gehen.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „VaporiZed“ ()

    Naja die implizierte Convertierung ist halt mit Vorsicht zu genießen... Kann gut gehen oder halt auch nicht.

    Gegenfrage: was spricht gegen Option Strict On?
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen

    Yanbel schrieb:

    mir fällt kein plausibler Grund ein

    Hier ist die Erklärung von Microsoft.
    Das sollte eigentlich schon reichen.

    Kurz:
    - IntelliSense-Unterstützung
    - Typüberprüfung zur Vermeidung von Typkonvertierungs-Fehlern
    - Beschleunigte Codeausführung durch Vermeidung unnützer Konvertierung
    - Vermeidung von Laufzeitfehlern wegen Late Binding
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „petaod“ ()

    Bei strict off weiss man einfach nicht, was man tut.
    Da geht sowas:

    VB.NET-Quellcode

    1. Dim sNum as String = 77
    Wer sowas programmiert, ohne sich zu wundern unterscheidet einen Integer nicht von einem String.
    Spätestens wenn er eine Liste nach Datum sortieren will kapiert er die Welt nicht mehr (weil Strings eben (meist) anders sortieren als Datumse).
    Es finden sich auf vbParadise so einige Threads, wo danach gefragt wird.

    Anners gesagt: Option Strict Off macht dumm.

    Jo, kann gut sein, wenn man c# gelernt hat, dass man dann nicht in diese Fallen dappt.
    Aber mit Vb von der Pike auf, oder gar von vb6 her ist das ein Riesen-Fortschritt: Datentypen wahrnehmen und wirkungsvoll einsetzen.

    Ich kann dir nur raten, in deinem neuen Umfeld zuzusehen, dass du da Strict On etabliert bekommst als Richtlinie. Kannst auch mal versuchsweise einzelne Projekte Projektweit auf Strict On setzen, und gucken, wieviele Type-Mismatches schon drinne versteckt sind.
    Ich fund da bei uns hunderte, und einige mit wirklich fieser Wirkung.

    Da gibts zB haufenweise Stellen, wo Nullable(Of Integer) als Integer verarbeitet wird. Dabei geht dann komplett verloren, dass in der Datenbank das Feld aber Nullable ist - und wenn da wirklich mal nix eingetragen wird, gibts ne Exception.
    Sowas geht lange gut, und ist längst ausgeliefert, ehe es bemerkt wird.
    Oder es wird sogar nie wirklich identifiziert, und unser Proggi ist halt manchmal bischen buggy.
    Moin @VaporiZed,
    danke dir für deine Anwort. Und deine Antwort in diesem Thread ist auch wie von dir gewohnt sauber erklärt und richtig, sehe ich absolut genauso. Es geht mir in diesem Thread auch weniger um die Vorteile von Option Strict On sondern vielmehr um das was von Visual Basic übrig bleibt, wenn ich Option Strict On verwende.

    Meine Frage zielt eher darauf ab, zu verstehen, warum ich Visual Basic verwenden soll, wenn ich mir den einzigen Vorzug gegenüber C#, nämlich dass der Compiler mir in bestimmten Bereichen, auch hin und wieder mal gewollt, Arbeit abnimmt, wegoptioniere. Dann kann ich auch gleich in C# schreiben. Es muss doch ein weiteres Alleinstellungsmerkmal geben, dass für VB spricht? Warum hält sich die Sprache immer noch, wo doch die meisten neuen großen Projekte ohnehin auf Cloud-Architektur bauen, in der man nun mal mit C# besser beraten ist? Warum macht sich Microsoft hier die Mühe zweigleisig zu fahren?

    Ich hoffe das war diesmal verständlicher?

    Moin @mrMo,
    Kurz gesagt nix. Aber bei Einschalten spricht auch absolut nichts mehr für Visual Basic.

    Moin @petaod
    Beantwortet nicht den Kern der Frage. Hab sie daher wie oben beschrieben neu formuliert.

    Moin @ErfinderDesRades,
    danke auch dir, habe mir meinen ersten Beitrag nochmal angeschaut und umformuliert (siehe oben), da die eigentliche Frage wohl nicht eindeutig war. Entschuldige dies.
    Also nochmal: Mir ist klar, was Option Strict On tut. Mir ist auch klar, dass es sinnvoll ist. Mir ist nicht klar, warum VB, vor allem wegen der diversen Nachteile von VB vs C#.



    Ein Computer wird das tun, was du programmierst - nicht das, was du willst.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Yanbel“ ()

    Ah, so meinst du: - nee, es gibt inzwischen keinen Grund mehr, VB gegenüber c# zu bevorzugen.
    Also die Linq-Syntax ist bei vb besser, aber auch in vb verwende ich fast nur Extensions.
    Der Select Case ist besser - naja, Gott.
    With-Block findich bequem zu coden - naja.
    Früher gabs Xml-AchsenEigenschaften, da konnte man mit Intellisense-Unterstützung gegen eine Xml-Datei coden, wenn man das Schema eingebunden hatte.
    Haben sie aber scheints gecuttet, das Feature.
    Der Vb-ObjectBrowser ist besser (ist aber auch schlechter geworden: in vb2010 hat er noch beerbte Interfaces mit angezeigt).

    Andererseits dass c# schnelleren Code kompiliert findich höchst uninteressant.
    Kein User bemerkt jemals die Millisekunde (und um mehr geht es nicht), die eine c#-Version schneller sein mag.

    Es gibt einige wenige Spezialbereiche, wo das von Belang sein mag - in meiner Praxis war es das noch nie.
    Performance wird durch guten Code erzielt, nicht durch einen dollen Compiler.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Yanbel schrieb:

    Warum macht sich Microsoft hier die Mühe zweigleisig zu fahren?
    Ich denke das ist historisch bedingt.

    Damals wurden VB.NET und C# als gleichwertige Sprachen für die .NET Umgebung eingeführt. Auf der einen Seite hat man damit die C, C++ und Java Entwickler ansprechen wollen, auf der anderen Seite wollte man die VisualBasic Gemeinde auf die neue Umgebung hiefen. Das mit der Gleichwertigkeit hielt sich eigentlich so lange, wie die Entwicklung der Sprachen und der Plattform allein bei Microsoft stattgefunden hat. Das Problem ist jedoch, dass die C# Community schneller gewachsen ist, als die VB.NET Community (ich glaube inzwischen ungefähr Faktor 10). Und nun kommt .NET Core, bzw. die gesamte OpenSource bewegung von Microsoft, wodurch natürlich für C# du ein wesentlich größeres Potential hast, Entwickler in der Community zu finden, die freiwillig Aufgaben übernehmen.

    Inzwischen hat Microsoft auch offiziell bekannt gegeben, dass VB.NET definitv NICHT mit der selben Geschwindigkeit Sprachfeatures erhalten wird, wie C#, auch wenn sie VB.NET weiterhin als "First Class Citizen" der .NET Welt erachten. Was auch immer das bedeuten soll.
    SIMDoku (Simple Dokumentenverwaltung)
    Mein Lernprojekt um die verschiedensten Facetten der .NET Entwicklung zu erkunden.
    GitHub

    VB Paradise Dark Theme
    Inoffizieller VB-Paradise Discord.
    @ErfinderDesRades: Ja, genau das habe ich mir nämlich auch gedacht, die Syntax ist einfach angenehmer.

    Ich lasse den Thread noch ein wenig offen, vielleicht hab ich ja tatsächlich noch was übersehen oder nicht bedacht. Vielen Dank auf jeden Fall an alle die so schnell geantwortet haben. ;)

    @EaranMaleasi: Ist wahrscheinlich echt nur ein historisches Ding. Und die Bedeutung deines letzten Satzes in Bezug auf Microsoft ist klar. Beide Sprachen sind gleich, aber eine ist halt gleicher als die andere :D


    Ein Computer wird das tun, was du programmierst - nicht das, was du willst.

    Yanbel schrieb:

    Es ist weniger compiler-nah, benötigt viel mehr Programmcode
    C# und VB.NET sind gleich weit vom Compiler / Prozessor entfernt, da beide Sprachen zuerst in Intermediate Language (IL) übersetzt werden und deswegen ineinander überführt werden können.
    VB benötigt nicht mehr Code, die Codezeilen sind etwas länger wegen der "ausschweifenden" Syntax.
    Ich hab mal eine Software-Firma erlebt, die mit VB.NET programmierte. Dort war das Problem, dass der Hut-aufhaber kein C# konnte oder wollte.
    Strict Off ist ein Rudiment aus der Basic-Steinzeit, und um mit diesem Code maximal kompatibel zu sein, ist das MS-Default Strict Off.
    So sollte den Leuten der Umstieg von VBX nach VB.NET schmackhaft gemacht werden.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    @RodFromGermany: Entschuldige aber das kann ich so nicht stehen lassen.

    zum Thema Compiler-nah: In Bezug auf die ursprünglichen Compiler und die MSIL hast du natürlich Recht, da gibt es wenige Unterschiede, aber Microsoft hat mit Projekt Roslyn vor Jahren angefangen einen offenen Compiler zu entwickelt, mit dessen Hilfe dir ein Großteil der Compiler-Funktionen per dll im .NET geöffnet werden. Bedauerlicherweise hat Microsoft die vollständige Funktionalität bis heute nicht in Visual Basic integriert, womit einzelne Compilerfunktionen nicht zur Verfügung stehen. Das Problem liegt hier weder in der Übersetzung in die Common Intermediate Language noch an der .NET-Klassenbibliothek sondern schlichtweg am Compiler für VB selbst. Die Compiler werden in den jeweiligen Sprachen geschrieben: Visual Basic Compiler in VB und C#-Compiler in C# und wie so oft hat Microsoft Visual Basic hier etwas stiefmütterlich behandelt. In diesem Zuge wurde auch die ursprüngliche Microsoft Intermediate Language (MSIL) durch die Common Intermediate Language (CIL) ersetzt. In Bezug auf die MSIL magst du Recht haben, da ist die Compilerfunktionalität nahzu equivalent. Was bei der CIL definitiv nicht der Fall ist.

    C# und VB brauchen gleich viel Code: Nein! Syntaktisch muss der Code das gleiche ausdrücken, das ist richtig, aber C# braucht im Vergleich zu VB etwa 20% weniger Zeichen um das gleiche auszudrücken. Liegt denke ich zum Großteil an den geschweiften Klammern. Habs gerade mal mit ein paar meiner Funktionen überprüft und komme auf Werte zwischen 17% und 23% Unterschied in der Anzahl der Zeichen.

    Und nun zu Option Strict On: Wenn Option String Off ein Relikt aus der VB6 Steinzeit wäre, wieso besteht dann in C# ein ähnliches Konstrukt mit der Unsafe Compiler-Option? Spätestens das hätten sie bei der Einführung einer für Microsoft komplett neuen Sprache weglassen können. Sie haben sich aber bewusst dagegen entschieden und es integriert. Außerdem neigt Microsoft eher dazu nach dem Friss-oder-Stirb-Prinzip konsequent Relikte aus ihren Produkten zu entfernen. Man kann an dieser Stelle also festhalten, dass diese Option von Microsoft durchaus gewollt und auch unterstützt wird, auch wenn fraglich ist, warum dies die Standardeinstellung ist.


    Ein Computer wird das tun, was du programmierst - nicht das, was du willst.
    unsafe ist nicht Option Strict Off.
    Mit unsafe bekommst du in C# direkten Zugriff auf Pointer und alles was dazu gehört. Jedoch musst du dich nach wie vor der statischen Typisierung beugen.

    Was du wohl eher meinst ist die DLR oder auch Dynamic Language Runtime. Damit sind sogar Konstrukte wie

    C#-Quellcode

    1. dynamic awesomeVar = 0;
    2. Color[] colors = awesomeVar.Split('-');

    möglich, ohne dass der Compiler einen Fehler anmeckert. Dafür brauch es aber kein unsafe
    SIMDoku (Simple Dokumentenverwaltung)
    Mein Lernprojekt um die verschiedensten Facetten der .NET Entwicklung zu erkunden.
    GitHub

    VB Paradise Dark Theme
    Inoffizieller VB-Paradise Discord.
    @EaranMaleasi: Hab unsafe ehrlich gesagt noch nie benutzt, dachte immer das wäre dafür da, Typisierungen zu umgehen. Danke für die Richtigstellung ;)

    An Dynamic habe ich noch gar nicht gedacht, aber da hast du absolut Recht. Spätestens hier haben wir auch in C# eine Möglichkeit die Tyisierung zu umgehen.


    Ein Computer wird das tun, was du programmierst - nicht das, was du willst.

    Yanbel schrieb:

    Spätestens hier haben wir auch in C# eine Möglichkeit die Tyisierung zu umgehen.


    Nein hast Du nicht. Dynamic legt den Typ erst zur Laufzeit fest. Dynamic hat keinen Typ, solange das Programm nicht läuft. Wogegen Du bei Option Strict Off eine Variable vom Typ Integer mit einem String belegen kannst und die Konvertierung für Dich vorgenommen wird.
    Die Unendlichkeit ist weit. Vor allem gegen Ende. ?(
    Manche Menschen sind gar nicht dumm. Sie haben nur Pech beim Denken. 8o

    How to turn OPTION STRICT ON
    Why OPTION STRICT ON

    C#-Quellcode

    1. dynamic var1 = 0;
    2. string var2 = var1;


    VB.NET-Quellcode

    1. Dim var1 = 0
    2. Dim var2 As String = var1


    Beide Beispiele lösen keine Kompilierzeitfehler aus... Demnach ist meine Aussage richtig, dass ich eine explizite Typisiserung über Dynamic umgehen kann.

    Nein hast Du nicht. Dynamic legt den Typ erst zur Laufzeit fest

    Und was macht VB.NET bitte in meinem oben genannten Beispiel? Richtig, genau das gleiche.

    Wogegen Du bei Option Strict Off eine Variable vom Typ Integer mit einem String belegen kannst

    "kannst" ist hier das richtige Schlüsselwort. Leider vollständig am Thema vorbei, weil: Ich will ja das genaue Gegenteil. Meine Aussage war, dass ich Typisierungen damit umgehen kann und diese Aussage ist korrekt.
    Das VB eine interne Konvertierung durchführt ist eine tollle Sache, hat aber nichts mit meiner Aussage zutun.


    Ein Computer wird das tun, was du programmierst - nicht das, was du willst.
    @Yanbel Falls es da Unklarheiten gibt, kannst Du ja mal im IlSpy die eine oder andere Rückübersetzung des Codes nach vb bzw. c# ansehen.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Kenn ich, hab ich für den Umstieg einige Mal benutzt. Aber danke, dass du darauf aufmerksam machst. Sollte in diesem Thread auf jeden Fall erwähnt werden. ;)

    EDIT: Ich denke die Debatte kann man endlos fortsetzen, aber meine Hauptfrage ist denke ich geklärt. Danke nochmal an alle. Ich schließe den Thread jetzt.


    Ein Computer wird das tun, was du programmierst - nicht das, was du willst.