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

  • VB.NET

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

    Ich weiß jetzt nicht, ob das schon gepostet wurde, aber hier noch was:

    VB.NET-Quellcode

    1. If CheckBox1.Checked Then
    2. Button1.Visible = False
    3. Else
    4. Button1.Visible = True
    5. End If
    Finde ich grausam... Viel kürzer und einfacher:

    VB.NET-Quellcode

    1. Button1.Visible = Not CheckBox1.Checked()
    kann mich nur anschließen:

    statt:

    VB.NET-Quellcode

    1. textbox1.text = textbox2.text
    2. textbox2.text = textbox1.text


    lieber:

    VB.NET-Quellcode

    1. dim txt1 as string
    2. txt1 = textbox1.text
    3. dim txt2 as string
    4. txt2 = textbox2.text


    oder :

    VB.NET-Quellcode

    1. dim txt1 as string = textbox1.text
    2. dim txt2 as string = textbox2.text


    sry wegen fehler xD

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

    freakshow10000 schrieb:

    VB.NET-Quellcode

    1. textbox1.text = textbox2.text
    2. textbox2.text = textbox1.text
    Der Code funktioniert nicht mal (richtig).

    freakshow10000 schrieb:

    VB.NET-Quellcode

    1. dim txt1 as textbox1.text
    2. dim txt2 as textbox2.text
    Und da wird mir ja übel!

    Statt:

    freakshow10000 schrieb:

    VB.NET-Quellcode

    1. dim txt1 as string
    2. txt1 = textbox1.text
    3. dim txt2 as string
    4. txt2 = textbox2.text
    kann man auch:

    VB.NET-Quellcode

    1. dim txt1 as string = textbox1.text
    2. dim txt2 as string = textbox2.text


    gruß

    picoflop schrieb:

    VB.NET-Quellcode

    1. Private Sub DeleteFile(byval BrochnikosBalmsa As Boolean)
    2. if (BrochnikosBalmsa) then
    3. Drachnik
    4. else
    5. Sputnik
    6. endif
    7. End Sub


    Das ganze soll einfach nur verdeutlichen, dass "DarfDas" ggfs nicht in einer Sprache geschrieben wurde, die man versteht.


    was hat die Sprache damit zutun? Ob man von xy ein Wahr erwartet oder von xy == wahr ein wahr erwartet?

    Stefan2 schrieb:

    Als schlechten Stil bezeichne ich alles es erschwert den Code zu verstehen und alles was ein erhöhtes Risiko für mögliche Fehler enthält.

    Die Frage, ob man nun „If move Then“ schreiben sollte oder lieber „If move = True Then“, ist damit doch absolut lächerlich. Beides kann man ohne Probleme verstehen. Keines hat irgend einen Nachteil. Befasst Euch doch lieber mit wirklichschlechtem Code. Ich bin mir sicher, wenn man nur genügend lange in so einem Forum dabei ist, bekommt man allerhand zu sehen.


    wenn ich ganz pingelig werde, dann ist das 1 Vergleich mehr

    if move then

    move auswerten
    mit true vergleichen
    verzweigung steuern

    oder

    if move = true then

    move auswerten
    mit true vergleichen
    das ergebnis mit true vergleichen (ausdruck mit true vergleichen von if erwartet)
    verzweigung steuern

    da hast du einen Takt mehr :D
    Nicht zwangstläufig. Erstelle mal versuchsweise ein Prog mit So einer Abfrage ohne = True. Dann erstelle das und guck dir das im .net Reflector an. Ich glaub AFAIK dass da dann trotzdem = True steht, da im MSIL-Code das so steht.
    | Keine Fragen per PN oder Skype.

    dognose schrieb:



    Quellcode

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13



    Dim element As String = "PfadZurDateiAusVorherigenFunktionen"

    Try
    My.Computer.FileSystem.DeleteFile(element)
    Catch ex As System.IO.FileNotFoundException
    MsgBox("Datei nicht gefunden")
    Catch ex As ArgumentNullException
    MsgBox("Kein Pfad übergeben")
    Catch ex As AccessViolationException
    MsgBox("Keine Rechte")
    Catch ex As UnauthorizedAccessException
    MsgBox("Datei gerade in Verwendung")
    End Try


    find ich nicht gut..
    was hällste davon:

    VB.NET-Quellcode

    1. try
    2. catch ex as Exception
    3. msgbox(errortostring)
    4. end try
    Nicht gut, der andere Try Catch Code leifert mehr Fehlerinformationen, die man zudem auch noch selber bestimmten kann, bzw. nicht umbedingt eine Fehlerausgabe machen muss sondern wenn z.b. File nicht exisitert erstellen. Der Pfad nicht stimmt einen DefaultPfad setzten und soweiter. Das mit der allgemeinen Exception abfangen nicht möglich!

    vanitas-mundi schrieb:

    singu schrieb:

    Also ich deklariere meine Variablen so.

    Lokale Variable (Dim, Private): locName
    Globale Variable (Public): globName

    Deklariere meine Variablen so
    lokale: dim fileName as string
    klassenweite: private _FileName as string
    und globale gibt es bei mir nicht :)

    hackerking schrieb:

    Und ich mach es so^^:
    Lokal: Dim, manchmal auch Private^^
    Klassenweit: Private
    Global: Gloabal, manchmal Global^^

    Und namen sind bei mir einfach abkürzungen der variable z. B.: strName, intCount, blKill, bytFile...^^
    Ich weiß wie man Variablen deklariert, aber mir ging es um den Namen der Variable
    Zu

    Try
    Catch ex As HalloWeltException
    Catch ex As AndereException
    End Try

    Ich denke, so ist es am Besten:

    VB.NET-Quellcode

    1. Try
    2. 'Der Code
    3. Catch ex As 'Erwartete Fehler (z.B. Update überprüfen - "Internet nicht an")
    4. Catch ex As Exception 'Alles andere
    5. Throw ex
    6. End Catch


    EDIT:

    Und noch einen (Grade erst gelesen)

    VB.NET-Quellcode

    1. Dim Haha As String
    2. If Haha = "" = False Then 'Das mein ich
    3. ...
    4. End If


    Vielviel besser:

    VB.NET-Quellcode

    1. If Haha <> "" Then
    2. ...
    3. End If


    Zur Namensgebung:

    Contorls versehe ich mit einem Präfix (txtText, cmdButton, dlgDialog, cmbCombbox)
    und Variablen mit Beschreibungen, bei denen jeder Bestandteil mit einme Grossbuchtaben anfängt (Player1Name, TestVariable)
    Temporäre Variablen (Counter...) so: bei i's: (i, i2, i3...) bei Temporären anderen: (Temp, Buf, Buffer, StrBuf, CharBuf, IntBuf)

    und Subs/ Functions wie normale Variablen, mit xml-Tags, wenn Sie Public sind
    Beispiel Code (Frei erfunden):

    VB.NET-Quellcode

    1. Public Leben As Integer
    2. Public Geld As Integer
    3. '''<summary>
    4. '''Fügt dem Spieler Schaden zu
    5. '''</summary>
    6. '''<param name=Damage>Höhe des Schadens</param>
    7. Public Sub DealDamage (Damage As Integer)
    8. Leben -= Damage
    9. If CheckForDeath() Then
    10. ' Code für verloren
    11. End If
    12. End Sub
    13. Private Function CheckForDeath() As Boolean
    14. If Leben <= 0 Then
    15. Leben = 0
    16. Return True
    17. Else
    18. Return False
    19. End If
    20. End Sub

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

    grausam finde ich auch eine GoTo anweisung zum verlassen einer schleife, sub, function:

    VB.NET-Quellcode

    1. sub abc()
    2. '...
    3. if a = b then
    4. GoTo Ende
    5. end if
    6. '...
    7. Ende :
    8. end sub


    lieber so:

    VB.NET-Quellcode

    1. sub abc()
    2. '...
    3. if a = b then
    4. exit sub
    5. end if
    6. '...
    7. end sub


    das gleiche gilt auch für das frühzeitige verlassen von Schleifen mit
    Exit Loop
    Exit For
    etc.
    also nach meiner neuesten erkenntnis gehört goto eh zum alten eisen und sollte nicht mehr genutzte werdem ;)
    ich frage mich nur wer so etwas entscheiden karl lagerfeld ? ...
    Grüße Manu

    Was Gott dem Menschen erspart hat, kann der Computer.
    Billy ©, (*1932), Schweizer Aphoristiker
    Quelle: www.Aphorismen.de
    Noch besser als:

    VB.NET-Quellcode

    1. If Haha <> "" Then
    2. ...
    3. End If


    Ist es einfach If Not zu verwenden, lässt sich deutlich einfacher lesen als Größerkleiner.

    VB.NET-Quellcode

    1. If Not Haha = "" Then
    2. End If


    Dies geht natürlich auch mit weiteren Bedingungen

    VB.NET-Quellcode

    1. If Haha = "Text" And Not Huhu = "" Then
    2. End If