Was ist eig so schlecht an Option Strict OFF?

  • Allgemein

Es gibt 21 Antworten in diesem Thema. Der letzte Beitrag () ist von jvbsl.

    Was ist eig so schlecht an Option Strict OFF?

    Was ist eig so schlecht an Option Strict OFF?
    So spart man sich doch ne menge Code.

    Edit by der_Kurt:
    Ich lagere das thema aus, da es mit dem Ursprungsthema direkt nichts zu tun hat.
    * Thema ausgelagert *

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „der_Kurt“ ()

    Aber heimst sich um so mehr Probleme ein...
    Dadurch wird das Programm nicht nur langsamer, sondern bei größeren Projekten werden Fehler komplett unauffindbar, die manchmal auftreten manchmal nicht uns sich nur bedingt an den stellen auswirken, an welchen Falsch programmiert wurde...
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---

    Versuche mal - ohne Visual Studio zu starten - herauszufinden, was beim Klick auf den Button passiert.

    VB.NET-Quellcode

    1. Option Strict Off
    2. Public Class Form1
    3. Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
    4. Dim i As Integer = 1.5
    5. If i = 1.5 Then MessageBox.Show("I = TRUE")
    6. End Sub
    7. End Class


    Die implizite Typkonvertierung (Option Strict Off) überlässt VB das Umwandeln von Daten in anderen Datentypen.
    Option Strict ON verhindert das und zwingt die Programmierer dazu, das selbst zu machen, und sich mit den Fehlern zu beschäftigen.

    So spart man sich doch ne menge Code.
    Für deine Zukunft: Beim Programmieren geht es nicht darum, wenig Code zu schreiben, sondern nachvollziehbaren und richtigen Code zu verfassen.

    Stelle dir das so vor:

    Um eine gute Heftführung in der Schule zu haben, musst du immer ein Datum hinschreiben.
    Es ist zwar mehr "Schreibarbeit", aber richtig und du weißt immer von wann der Text z.B. ist.

    LG

    Ich mag diese Option Garnicht, größere sachen Konvertiere ich in Treadhs ;)

    Ich programiere auch mit Option Strict ON

    Jedoch hatte ich mal ziemlich Probleme bei der Konvertierung einiger VB6
    Prozeduren, die auf Exceldaten zugegriffen hatten. Da es nicht
    vorauszusehen war, welchen Typ die eingegebenen Exceldaten in der
    Zelle haben würden. In diesem Modul habe ich dann Option Strict Off
    geschaltet, weil ich wirklich zu faul war, alles neu zu schreiben.

    Lightsource schrieb:

    Prozeduren, die auf Exceldaten zugegriffen hatten. Da es nicht
    vorauszusehen war, welchen Typ die eingegebenen Exceldaten in der
    Zelle haben würden. In diesem Modul habe ich dann Option Strict Off
    geschaltet, weil ich wirklich zu faul war, alles neu zu schreiben.

    zustimm.
    Es ist eh sinnvoll, Com-InterOp-Geschichten in spezielle Module und Klassen zusammenzufassen oder gar zu kapseln.
    Lustigerweise zu den neuesten Features in c# gehört der Datentyp "Dynamic", wo alles reinkann. Ist extra für Com-InterOp in die Sprache aufgenommen worden, und ist ein Datentyp, der nicht typüberprüft wird, also eiglich ein "Strict Off" - Datentyp.

    Manawyrm schrieb:

    er will wahrs. sagen, dass es ihm egal ist, wie schrottig er programmiert, weil er in threads auslagert.

    Nein dass will ich nicht, aber bei Älteren Coodes, und vor allendingen bei Coodes wo ich nicht weiß Welcher Typ später rauskommt schalte ich diese Option aus, wen ich alerdings weiß dass es zu keinen Konflickten kommt, dann schalte ich diese option ein.

    option infer ist bei mir eigendlich immer an ;)

    Option Strict Nicht-On ist so ein Relikt aus alten VB-Nicht-Net-Tagen, als eine Variable mit

    VB.NET-Quellcode

    1. Dim i
    deklariert werden konnte, da gab es den Typ Variant als Obertyp.
    Leute, die mit Option Strict Nicht-On arbeiten, kommen dannzum Forum und klagen über Probleme, die mit Option Strict On nicht aufgetreten wären.
    Wenn Du mit "anständigen" Programmiersprachen arbeitest, steht die Frage Option Strict überhaupt nicht, die ist von vorne herein auf True gesetzt und kann nicht umgestellt 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!

    Nein dass will ich nicht, aber bei Älteren Coodes, und vor allendingen bei Coodes wo ich nicht weiß Welcher Typ später rauskommt schalte ich diese Option aus, wen ich alerdings weiß dass es zu keinen Konflickten kommt, dann schalte ich diese option ein.

    Guck dir unbedingt TypeOf an...

    Jedoch hatte ich mal ziemlich Probleme bei der Konvertierung einiger VB6
    Prozeduren, die auf Exceldaten zugegriffen hatten. Da es nicht
    vorauszusehen war, welchen Typ die eingegebenen Exceldaten in der
    Zelle haben würden. In diesem Modul habe ich dann Option Strict Off
    geschaltet, weil ich wirklich zu faul war, alles neu zu schreiben.

    Nicht so faul: Komplett neu machen mit dem dazugehörigen .Net Wrapper^^
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---

    die letzten beiden Posts betrachtet: Warum soll man wegen genannten Gründen mit C# arbeiten, wenn man das mit VB mit einer einzigen Einstellung, einer einzigen Zeile ändern kann. VB ist nun mal rückwärtskompatibel. Is so!

    Hilfe in diesem Fall: Eigenschaften und Bereiche der verschiedenen Datentypen lernen, DirectCast, TryParse auf MSDN büffeln.

    Bitte verzichtet hier auf den klassischen VB - C# - Flamewar. Wäre nett, wenn wir hier mal einen Referenz-Thread zustande bekommen, auf den man auch verweisen kann.

    Beep! schrieb:

    RodFromGermany schrieb:

    Wenn Du mit "anständigen" Programmiersprachen arbeitest, steht die Frage Option Strict überhaupt nicht, die ist von vorne herein auf True gesetzt und kann nicht umgestellt werden.


    Ok ich denke darin liegt mein Problem. Ich habe an meinem Taschenrechner das programmieren gelernt (TIBasic). Da war es völlig normal so etwas zu machen:

    VB.NET-Quellcode

    1. If i = 1.5 Then MessageBox.Show("I = TRUE")



    Die Site (http://home.arcor.de/eckardahlers/Programmer/Blogs/WarumStrictOn.html) hab ich nicht ganz 100%-ig verstanden, da ich mich mit Typen wie DataRow und .. noch nicht auseinandergesetzt habe.

    Wenn ich jetzt nochmal zusammenfasse stelle ich fest, das es zwar auch Vorteile mit sich bring Strict auf ON zu stellen, aber sonderlich wuchtig fand ich die Argumente jz nicht.

    •Man spart nicht viel Code
    •Mal mehr mal weniger Übersichtlichkeit, Stil
    •Fehler sind leichter zu finden
    •Das Programm läuft schneller (wirklich? warum das denn?)

    Vielen Dank für die vielen Antworten

    VB.NET-Quellcode

    1. Dim i As Integer = 1.5
    2. If i = 1.5 Then MessageBox.Show("I = TRUE")


    Das Problem bei diesem Code liegt eigentlich darin, dass VB in Zeile 1 den Wert in eine Ganzzahl-Variable "reinpresst"
    Wenn du in einem großen Projekt (>1000 Zeilen, mehrere Dateien, usw...) auf Fehlersuche gehst, dann wird dir dieser Fehler nicht unbedingt sofort ins Auge stechen.
    Die Messagebox aus dem Beispiel wird niemals ausgefürt, weil "i" in der zweiten Zeile nicht 1.5 ist, obwohl du diesen Wert darüber zugewiesen hast.

    Option Strict On macht dich darauf aufmerksam, dass hier was nicht passt.

    • Man spart nicht viel Code - Komplett absolut total EGAL! - siehe oben. Code muss lesbar sein.
    • Mal mehr mal weniger Übersichtlichkeit, Stil. - Umwandlung mit den korrekten Funktionen = Übersicht
    • Fehler sind leichter zu finden - TRUE
    • Das Programm läuft schneller (wirklich? warum das denn?) - Das halte ich für ein Gerücht. Umgewandelt wird auf jeden Fall. Einmal von VB implizit, im anderen Fall von dir explizit

    Wenn Du Dir nach längerer Zeit Deinen Code ansiehst, wirst Du ihm mit Option Strict On leichter verstehen, weil er logischer ist.
    Wenn Du mit mehreren Leuten in einem Team programmierst, müsst Ihr Euch auf Codierungsrichtlinien einigen, und glaub mir, eine dee ersten dieser Richtlinien ist Option Strict On.
    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!

    Das halte ich für ein Gerücht. Umgewandelt wird auf jeden Fall. Einmal von VB implizit, im anderen Fall von dir explizit

    Nicht Option Strict On macht es schneller, aber wenn man die Typen selber umwandelt, denn man selbst weiß ja schließlich was man benötigt, VB ansich muss erst gucken, dies und das, dann muss ich da das casten usw...
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---

    jvbsl schrieb:

    VB ansich muss erst gucken, dies und das, dann muss ich da das casten usw...
    Ich denke mal, das passiert zur Compile-Zeit, hat also auf die Performance keinerlei Auswirkung.
    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!