Ist das Schlechter Stil?

SideWinder

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

SideWinder

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

MfG SideWinder

rüdiger

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

junix

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

SideWinder

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

junix

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

SideWinder

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

rüdiger

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.

junix

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

SideWinder

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

HumeSikkins

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.

Daniel E.

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 :).

Bashar

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.

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

Stefan.

ScriptGod

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;

HumeSikkins

@DStefan
Was gute Namen doch alles ausmachen

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