3. Ist das Schlechter Stil?

Ist das Schlechter Stil?

  • S
     

    case VK_DOWN:
    if(yCaret!=MaxRows-1&&++yCaret);
break;

    Kurze Erklärung: Caret ist der "Textcursor", also der Strich den ihr bei Texteingaben an der jetzigen Position seht ;).

    Sollte der User nun VK_DOWN(Pfeil nach unten) drücken wird überprüft ob der Cursor nicht bereits in der letzten Zeile steht und wenn nicht die Y-Position von Caret um eins erhöht.

    Dies ersetzt letzten Endes:

    case VK_DOWN:
    if(yCaret!=MaxRows-1)
    {
        ++yCaret;
    }
break;

    Ist diese Verkürzung in die if-Abfrage schlechter Stil? Oder kann man das beruhigten Gewissens stehen lassen?

    MfG SideWinder

    0
  • J

    SideWinder schrieb:

    Ist diese Verkürzung in die if-Abfrage schlechter Stil? Oder kann man das beruhigten Gewissens stehen lassen?

    Rein dokumentarisch empfinde ich das Teil als ne Katastrophe... ausserdem wage ich zu behaupten, dass diese Art von "Optimierung" völlig unnötig ist, da hier bestimmt der Compiler bereits das best mögliche rausholt...

    Ich frage mich sowieso wieso viele derart mit Zeichen geizen, als würde ihnen für jedes Zeichen 1€ verrechnet... Was kostet es dich hier, wenn du 3 Returns, 2 Leerzeichen und 2 geschweifte Klammern und vielleicht 3 Sekunden Tippzeit mehr investierst, wenn du dafür danach auf 1 Blick erkennst, was du eigentlich wolltest?

    -junix

    0
  • S

    Naja da gibt es ja nicht nur VK_DOWN sondern auch noch Left, Up, etc. und mit der Zeit wird bei Methode #2 der Code doch etwas lang. Und man kann sich dann eben beim Betrachten nicht mehr auf das Wesentliche konzentrieren sondern sieht elendslange Ketten von solchem Unsinn.

    Wobei eine weitere Möglichkeit Platz zu sparen wäre dann "case Anweisung break" in eine Zeile zu schreiben.

    Man kann ja beim ersten Mal dazuschreiben was gemeinst ist (Kommentar), dann sollte das Lesen kein Problem darstellen.

    MfG SideWinder

    0
  • S

    Da bleibt es ewig hängen, drückt man nochmal "Absenden" und schon ists einmal zuviel :(.

    MfG SideWinder

    0
  • R

    also, ich würde die 2. Variante nehmen, da sie deutlich besser zu verstehen ist. Außerdem könnte ein schlechter Compiler vielleicht die 1. Variante nicht gut optimieren, da er vielleicht noch einen Vergleich für ++foo == 0 einbaut 🙂

    0
  • J

    SideWinder schrieb:

    Man kann ja beim ersten Mal dazuschreiben was gemeinst ist (Kommentar), dann sollte das Lesen kein Problem darstellen.

    Wozu Kommentar schreiben, wenn man den Code selbsterklärend halten könnte? Wenn dir das zuviele Zeilen werden, lass doch den Block weg (die öffnende und schliessende Klammer) und häng die Zeile direkt so an:

    if (condition)
    do_something();

    -junix

    0
  • S

    junix schrieb:

    SideWinder schrieb:

    Man kann ja beim ersten Mal dazuschreiben was gemeinst ist (Kommentar), dann sollte das Lesen kein Problem darstellen.

    Wozu Kommentar schreiben, wenn man den Code selbsterklärend halten könnte? Wenn dir das zuviele Zeilen werden, lass doch den Block weg (die öffnende und schliessende Klammer) und häng die Zeile direkt so an:

    if (condition)
  statement;

    -junix

    Schon gut, habt mich überredet - werde wieder Codeblöcke draus machen.

    Deine Beispiel unten mag ich irgendwie nicht. Mir ist klar wie es funktioniert, und mir sind als ich es noch benützt habe auch keine Fehler damit passiert.

    Aber ich benütze nun eigentlich immer und überall:

    if(condition)
{
    statement
}

    Dann finde ich meine Blöcke leichter - in dem Fall ein dämliches Argument, da ja mein Beispiel noch extremer ist.

    Also ändern 👍

    MfG SideWinder

    0
  • J

    SideWinder schrieb:

    case VK_DOWN:
    if(yCaret!=MaxRows-1)
    {
        ++yCaret;
    }
break;

    da fällt mir auf... prüf besser auf

    yCaret < MaxRows

    Das ist sicherer...

    -junix

    0
  • S

    Schneller auch?

    yCaret wird sicher nirgendwo sonst verändert - außer in diesen Befehlen. Deswegen würde ich in diesem Fall nicht die sichere sondern die schnellere Variante benützen.

    Und ich dachte != ist einfach zu prüfen als <.

    MfG SideWinder

    0
  • R

    nö, AFAIK sind auf x86er (ich geh davon aus, dass du auf einem x86er arbeitest, weil ich ja weiss, dass du auf jeden Fall Windoze nimmst 😉 und das gibt dir ja eh keine anderen Möglichkeiten :p ), sind AFAIK alle bedingten Sprünge gleich schnell.

    dh. < > != == etc. sollten gleich schnell sein.

    0
  • J

    Jo, vor Allem muss er ja bei deiner Version vorher noch rechnen... und auch wenn. In diesem Fall wirst du die Geschwindigkeit kaum spüren. Da gibts andere Dinge bei denen Optimieren viel eher gerechtfertigt ist...

    -junix

    0
  • S

    kingruedi schrieb:

    nö, AFAIK sind auf x86er (ich geh davon aus, dass du auf einem x86er arbeitest, weil ich ja weiss, dass du auf jeden Fall Windoze nimmst 😉 und das gibt dir ja eh keine anderen Möglichkeiten :p ), sind AFAIK alle bedingten Sprünge gleich schnell.

    dh. < > != == etc. sollten gleich schnell sein.

    Gut aber ist das auf dem Toaster auch so? Mein Programm läuft auf einem Toaster, da die naturgemäß nicht so schnell sind muss ich natürlich bei solchen Vergleichen sparen ;).

    Danke, also dann baue ich auch noch die Sicherheitsabfrage ein.

    MfG SideWinder

    0
  • H

    Hallo,
    also ich sehe das Richtung junix.
    Geschmacklich gefällt mir schon mal garnicht, dass du keine Leerzeichen bei den Operatoren verwendest.
    Ich halte die verbreitete Regel: Op1 binOp Op2 (-> 22 + 33)
    für sehr viel angenehmer zu lesen als Op1binOpOp2 (->22+33)

    Das ++yCaret aber in die if-Bedingung zu packen halte ich für missbrauch. Schließlich bedeutet das für die Bedingung if (a && true). Wenn nicht, ist irgendwas mit deinem Programm kaputt. Auf jeden Fall glorifizierst du den Seiteneffekt.

    Und man kann sich dann eben beim Betrachten nicht mehr auf das Wesentliche konzentrieren

    Wenn es darum geht, dann würde ich auch nur das wesentliche Hinschreiben. Wichtig ist, dass beim VK_DOWN der yCaret erhört wird:

    case VK_DOWN: incYCaret(); break;

    Fertig.

    Das kostet dich zwar letztlich wohl ein paar Zeilen mehr, aber erstens wird der Code klarer und zweitens verstreust du nicht überall diese != MaxCaret-1 abfragen.

    0
  • D

    HumeSikkins schrieb:

    Das ++yCaret aber in die if-Bedingung zu packen halte ich für missbrauch.

    Eigentlich ist

    yCaret != MaxRows-1 && ++yCaret;

    auch Mißbrauch, wird aber wenigstens von C- und Perl-Programmieren auf den ersten Blick verstanden :).

    0
  • B

    Nochmal zur Anfangsidee: Wozu überhaupt eine if-Anweisung, wenn von der Bedingung nichts abhängt? Ausdrücke auswerten kann man auch ohne, d.h. der Code sähe so aus:

    case VK_DOWN: 
    yCaret != MaxRows - 1 && ++yCaret;
    break;

    Nicht, dass ich das so empfehlen würde, aber das sieht man tatsächlich hin und wieder.

    0
  • ?
     

    case VK_DOWN:
   if(!atEnd()) goDown(); break;

    Stefan.

    0
  • S
     

    case VK_DOWN: 
    if(yCaret!=MaxRows-1&&++yCaret); 
break;

    also sowas würd ich auf keinen fall verwenden! wenn du das programm allein schreibst ist das vielleicht noch ok, aber wenn später jemand deinen code lesen oder sogar verändern muss hat der dann en zeimliches prob. weil man da nicht genaut blickt, was du eigentlich machen wolltest. leider sieht man solche code oft in der crt 😕

    auf jeden fall mindestens sowas

    case VK_DOWN: 
    if(yCaret!=MaxRows-1) 
        ++yCaret; 
    break;
    0
  • H

    @DStefan
    Was gute Namen doch alles ausmachen 🙂

    Genau auf sowas wollte ich mit meinem, zugegebenermaßen nicht gelungenen, Beispiel hinaus.

    0
Anmelden zum Antworten