C# Anfänger Frage über if else in Windows Forms anwendung

roker002 schrieb:
Klar könnt ihr alles unnötige rausfiltern. Aber man sollte auch bedenken, dass durch diese Abkürzungen im Code die Fehler nicht so schnell herauslesbar sind. Ich finde solche Codeoptimierungen als Suboptional, da der Compiler selbst den Code optimiert. Also wozu einen undurchsichtigen Code der schlecht lesbar ist, wenn es eh nachher noch einmal optimiert wird.
E-Laurin versteht auch was ich meine.

Wenn man Code wie folgt schreibt, ist es klar, dass man diesen nicht versteht.

Code:
int a = 22;
...
if((a < 50) == true)
{
    //dann mache etwas
}

Was hier überprüft wurde, kann keiner erahnen.
Daher sollte schon allein die Variable einen sprechenden Namen erhalten bzw kann die Validierungslogik in eine Methode ausgelagert werden, die nur diese Validierung ausführt. Und dann ist der Name der Methode genauso verständlich. Die Benamung sollte auch im Kontext zum Klassennamen stehen.

Eine Idee wäre:
Code:
int calculateAgeOfUser = 22;
...
if (IsCalulatedAgeLessThen50(calculateAgeOfUser))
{
     // dann mache was
}

...
private static bool IsCalulatedAgeLessThan50(int calculatedAge)
{
      return calculatedAge < 50;
}
 
Zuletzt bearbeitet:
Heißt übrigens "less than".
Schon blöd gelaufen, wenn man wegen nichts meckert, aber selber nicht einmal Englisch kann...
 
> if((a < 50) == true)

Das meine ich nicht. a < 50 ist als Aussage klar genug. Es geht mir eher um Dinge wie
while (!Bedingung) { ... }
Wenn Bedingung eine oder mehrere Variablen beinhaltet, ist es oft nicht sofort ersichtlich, wann er genau die Schleife beendet. Sprechender Code hin oder her, solche Fälle gibt es einfach und das nicht zu knapp.

Da ist es dann einfacher zu verstehen, wenn man stattdessen
while (Bedingung == false) { ... }
hinschreibt.


Dieser Abkürzungswahnsinn ist heute, Gott sei Dank, nicht mehr so krass, wie es damals bei C war. Da wurde teilweise so viel abgekürzt, dass man Ewigkeiten brauchte, um zu verstehen, was da vor sich ging.
 
KamehamehaX10 schrieb:
Heißt übrigens "less than".
Schon blöd gelaufen, wenn man wegen nichts meckert, aber selber nicht einmal Englisch kann...

D.h. dann, dass jeder, der sich mal einen Schnitzer (Schreibfehler) leistet, nicht programmieren kann?
Dann sollte ich mir was anderes suchen oder auf das Ein-Finger-Adler-System umsteigen.

Zum Glück beherrscht Du alles :puuhh
 
Zuletzt bearbeitet:
Das ist ein Wortfehler, der zu einem komplett anderen Sinn führt. Es ist einfach nur schwachsinnig, jemandes Codestil zu kritisieren, wenn man doch eindeutig nicht einmal richtig bezeichnen kann. Was ist wohl der schwerwiegendere Fehler?

Und zu deinem Post: Geh woanders trollen. ;)
 
KamehamehaX10 schrieb:
Das ist ein Wortfehler, der zu einem komplett anderen Sinn führt. Es ist einfach nur schwachsinnig, jemandes Codestil zu kritisieren, wenn man doch eindeutig nicht einmal richtig bezeichnen kann. Was ist wohl der schwerwiegendere Fehler?

Für sowas gibt es "Code Review"
 
Zuletzt bearbeitet:
Ellinikoskaffes schrieb:
P.S. Mein Letztes Projekt was ich in der Schule abgegeben habe war ein "Windows form Programm" womit man Radio hören kann. :D Ihr Profis sagt natürlich ja ... das ist doch kinder kram... aber ich war voll glücklich darüber. :D
Bin ich der einzige, der sich daran stößt, dass jemand, der Probleme mit bedingten Anweisungen und Textfeldern hat, ein Webradio programmieren kann?
 
Smagjus schrieb:
Bin ich der einzige, der sich daran stößt, dass jemand, der Probleme mit bedingten Anweisungen und Textfeldern hat, ein Webradio programmieren kann?

Ja da hast du recht, dieses selsame Phenome habe ich auch bemerkt und frage mich wie zum teufel, habe ich das hingekriegt! :D Aber es Funktioniert :) Immerhin ist Programmierung lernen, wäre "lerning by doing" also ist es doch nichts verkertes, wenn man was geschaft hat.. :D:p
 
e-Laurin schrieb:
> if((a < 50) == true)
while (!Bedingung) { ... }
Wenn Bedingung eine oder mehrere Variablen beinhaltet, ist es oft nicht sofort ersichtlich, wann er genau die Schleife beendet. Sprechender Code hin oder her, solche Fälle gibt es einfach und das nicht zu knapp.

Da ist es dann einfacher zu verstehen, wenn man stattdessen
while (Bedingung == false) { ... }
hinschreibt.
da muss ich widersprechen, zumindest, was meine wahrnehmung angeht.
boolsche ausdrücke nochmals gegen true/false zu testen würde mich beim lesen des codes eher verwirren als helfen.
 
Es geht halt um Eindeutigkeit.

Ich finde auch, dass if(20 < 50) schon deutlich genug ist. Wenn man aber einen echten booleschen Wert nimmt, dann sollte man alles klar Definieren, egal ob eine Methode oder ein bool... meiner Ansicht nach hilft es in Anhieb, wenn man direkt schreibt was man macht.

Was ist leserlicher?

Code:
if(!Bedingung)
{
}
oder
Code:
if(Bedingung == false)
{
}

Ausrufezeichen wird beim Überfliegen komplizierten Codeteile schnell übersehen. Klar wenn man nur einen Ein-zeiler hat so kann man es auch sooo machen:
Code:
int x = Bedingung == false ? 100 : 0;


Aber was solls. Ihr sollte so programmieren wie ihr wollt.
 
Zuletzt bearbeitet:
maxwell-cs schrieb:
da muss ich widersprechen, zumindest, was meine wahrnehmung angeht.
boolsche ausdrücke nochmals gegen true/false zu testen würde mich beim lesen des codes eher verwirren als helfen.

Finde ich auch. Früher wäre ich da noch auf e-Laurins Seite gewesen, aber diesen Stil habe ich vor mir einigen Jahren wieder abgewöhnt. Meiner Meinung nach ist immer die kürzeste Schreibweise, die zum Ziel führt und klar die Absicht des Programmierers ausdrückt, zu bevorzugen.
 
Zurück
Oben