Angepinnt Beispiele für guten und schlechten Code (Stil)

  • VB.NET

Es gibt 269 Antworten in diesem Thema. Der letzte Beitrag () ist von Hinti.

    Nochwas:

    CChar("a") ist unnötig.
    "a"c ist besser. Dann hat man direkt ein Char. :)

    EDIT: Der VB-Compiler optimiert das weg. Trotzdem finde ich "a"c besser. :D

    lg SeriTools
    | Keine Fragen per PN oder Skype.

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

    FAtheone schrieb:

    Aber dein Beispiel könnte auch so lauten:

    Ja, aber dann wäre es schlechter Stil. Denn man setzt voraus, dass der Lesende weiß, dass ein Bool Variable in VB im Zweifel mit False initialisiert wird. Was ist, wenn der Leser zwar ein guter Programmierer ist, aber von VB wenig Ahnung hat? Er wird die Logik dann nicht auf Anhieb verstehen!
    If a = False Then -> False -> End If => a = True

    Ann. 2: a wird mit False init.:

    Ia a = False Then -> True -> a = True -> End If => a = True
    das versteh ich jetzt nicht ganz, meinst du etwa:
    If a = False Then a = True?
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---
    Es ist auch meiner Meinung nach besser Boolean erst zu überprüfen, ob man sie ändern muss, bevor man sie ändert

    Statt

    Quellcode

    1. weiter = True


    so

    Quellcode

    1. If Not weiter Then weiter = True


    Hab das sogar mal gemessen:
    Bei 100.000.000 Boolean (xD) brauch ich 1051 Millisekunden für den ersten Code (mit schleife alle durchgelaufen) und 1289 Millisekunden für den zweiten wenn alle geändert werden müssen. Müssen sie aber nicht geändert werden, brauch ich nur 693

    Das ändert sich denk ich dann auch, ob der Wert aus einer Funktion kommt oder nur ein Merker darstellen soll

    huttERic schrieb:

    ...
    In C# gibt es dafür jedoch eine Möglichkeit, die es in VB nicht gibt. Man kann dort Kurzformen benutzen.

    PHP-Quellcode

    1. if (true)
    2. MessageBox.Show("Wahr");

    Und schon hat man einen Einzeiler, der folgendem Konstrukt entspräche (in VB):

    VB.NET-Quellcode

    1. If True Then
    2. MessageBox.Show("Wahr")
    3. End If

    Oder es gibt die Möglichkeit, folgendes zu tun: JA GIBT ES

    PHP-Quellcode

    1. true ? MessageBox.Show("Wahr") : MessageBox.Show("Falsch");

    ...
    Ja, die Möglichkeit gibts:

    VB.NET-Quellcode

    1. Iif(x = true,Messagebox.show("True"), Messagebox.show("False")

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

    Leseratte schrieb:

    Ja, die Möglichkeit gibts:

    VB.NET-Quellcode

    1. Iif(x = true,Messagebox.show("True"), Messagebox.show("False")



    Uhhh.. Das ist n grusliger Fehler.. :D

    Machs so:

    VB.NET-Quellcode

    1. Dim StringInMessageBox As String = "Unbekannt"
    2. String = IIf(True, "Boolean ist 'True'", "Boolean ist 'False'")


    Wobei ich bei Boolean gerne sowas verwende:

    VB.NET-Quellcode

    1. Dim Bool as Boolean = False
    2. MsgBox(Bool)
    3. Bool = True
    4. MsgBox(Bool)


    Denn Anweisungen können nicht in einer IIf-Anweinsung durch geführt werden.
    Beispiel:

    VB.NET-Quellcode

    1. IIf(True, Me.Hide, Me.Show)
    nein, da da ein DialogResult herauskommen sollte(aber anscheinend gehts ja gar nicht eine Funktion/Methode so direkt darin aufzurufen - weiß ich nicht, habs noch nie gebraucht eigt...^^)
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---
    Btw: Wenn das IIF das Ergebnis einer Funktion zurückgeben soll, eignet sich ein If(Expression,TrueReturn,FalseReturn) eher, da VB dann nur den wirklich zurückgegebenen Wert berechnet. Falls beide Berechnungen/Funktionen ausgeführt werden sollen - egal ob sie zurückgegeben werden oder nicht - ist IIF() die bessere Wahl. Da dieser Fall nur sehr selten auftritt -> If() statt IIf() benutzen. :D

    If() gibt es allerdings erst seit VB9 (VB2008).

    lg SeriTools
    | Keine Fragen per PN oder Skype.
    Ich kann einfach nicht anders... ich muss es Posten *g*

    VB.NET-Quellcode

    1. Function Bla()
    2. 1 On Error Resume Next : Bla = CInt(IIf(Mid("abcdefg123", InStr("abcdefg123", "123")) = 123 = True, Mid("abcdefg123", InStr("abcdefg123", "123")), 0)) : If Err.Number > 0 Then MsgBox(Err.Description & Chr(13) & Chr(10) & Chr(13) & Chr(10) & "In " & """" & Application.ExecutablePath & IIf(Command() <> "", " " & Command(), "") & """ in Zeile " & Erl(), 16, Application.ProductName) : Bla = 0 Else Bla = Bla
    3. End Function

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

    Wundert mich, wir sind auf Seite 7, und keiner hat daran gedacht.
    Man mag mich für altmodisch halten, aber für mich sind Kommentare (und jetzt auch XML-Kommentare und Regions) mitunter das wichtigste Kriterium für guten Code. Eine ausführliche Inline-Dokumentation ist mir persönlich wichtiger, als „if IsEsel = true then…“ oder „if IsEsel then…“ (wobei ich auch die zweite Variante bevorzuge).

    Mit Kommentaren meine ich nicht einzelne Wörter, sondern richtig ausführlich und, wo es nötig ist in ganzen Sätzen. Arbeitet man mit mehreren Entwicklern über Jahre an einem großen Projekt, macht sich das schnell bezahlt.
    Ich hatte schon so oft die Situation, dass ich dann einen Kollegen fragen musste, warum er da vor ein paar Jahren das so gemacht hat, wie er es gemacht hat, weil die Anwendung sich nun dort merkwürdig verhält.
    Ist da nichts vernünftig dokumentiert, dann weiß man’s in der Regel nicht mehr (ging mir selbst auch schon öfter so). Dann „korrigiert“ man die Stelle, an der die Anwendung sich merkwürdig verhält, und baut unter Umständen einen Bug dabei ein, weil dieses „merkwürdige“ Verhalten beabsichtig war. Oft tauchen die Bugs dann an einer ganz anderen Stelle auf, was die Fehlersuche erschwert.


    Für mich persönlich sind die Inline-Funktionen ein Unding. Schlecht zu lesen, und schlecht zu debuggen.
    Schlimm finde ich auch Codezeilen, mit vielen verschachtelten Funktionsaufrufen (der Parameter einer Funktion, kann eine Funktion sein, deren Parameter wiederum eine Funktion ist, usw.). Das spart zwar Platz, ist aber grausig zu lesen, und noch schlimmer zu debuggen.

    Wie man Variablen, Member, Funktionen, Klassen, Propertys usw. benennt, ist eigentlich definiert. Dafür gibt es ja die Camel- und Pascal-Notation.

    Strings, wie z.B. Text einer selbst definierten Fehlermeldung, gehören nicht in den Code, sondern in die Ressource-Datei.

    Benennungen von egal was (Variablen, Klassen, Funktionen, etc.) sollten eigentlich selbsterklärend sein. Hier lieber etwas längere Namen wählen (IteliSens hilft später beim Nutzen der Namen), auch wenn sie nur lokal sind.

    Quellcode

    1. Dim a as integer = 5


    Quellcode

    1. Dim Age as integer = 5

    In VB geht übrigens auch das:
    If True Then MessageBox.Show("Wahr")

    ->

    VB.NET-Quellcode

    1. MessageBox.Show("Wahr")

    Das ist immer wahr...

    If True Then MessageBox.Show("Wahr") Else MessageBox.Show("Falsch")

    ->

    VB.NET-Quellcode

    1. MessageBox.Show("Wahr")

    Ebenfalls
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---