Wie nennt ihr eine Boolean Variable, die auf Eingabe prüfen soll, ob Schleife verlassen werden soll?

hustbaer

zwutz schrieb:

hustbaer schrieb:

zwutz schrieb:

Andersrum weiß ich bei solchen Variablen aber auch auf dem ersten Blick, dass sie nur für die aktuelle Kontrollstruktur eine Relevanz haben

Woher denn?
Nachdem die keinen eigenen Scope hat...

Wenn ein kurzer Variablenname kurz vor oder innerhalb einer Kontrollstruktur auftaucht, dann wird sie auch nur zu deren Steuerung verwendet (also idR einen Abbruch einleiten)

Och ja, ist ja hübsch dass du dich daran hältst.
Nur woher soll ich das wissen wenn ich deinen Code lese. Oder den von jmd. anderem.

Und vielleicht hat der (andere) sich ja auch gar nicht daran gehalten.

SeppJ

Schonmal an for(bool b = true; b; ... gedacht?

zwutz

hustbaer schrieb:

Och ja, ist ja hübsch dass du dich daran hältst.
Nur woher soll ich das wissen wenn ich deinen Code lese. Oder den von jmd. anderem.

Und vielleicht hat der (andere) sich ja auch gar nicht daran gehalten.

mit dieser Argumentation könnte man jede Konvention vergessen

glaub mir einfach wenn ich sage dass wenn ich es verwende, dass die Verwendung aus dem Kontext auch für Querleser erkennbar ist.

Und Pauschalisierungen mag ich generell nicht (pun intended), von daher kann ich euch allein aus Prinzip schon nicht zustimmen

hustbaer

zwutz schrieb:

glaub mir einfach wenn ich sage dass wenn ich es verwende, dass die Verwendung aus dem Kontext auch für Querleser erkennbar ist.

Glaub mir einfach dass ich schon genug fremden (sowie eigenen) Code gelesen habe, um beurteilen zu können, dass ein "bool b" nichtssagend ist, und es lamit länger dauert den Sinn eines Codestücks zu erschliessen als mit einem "bool input_valid".

EXDW

eingabeNochmal schrieb:

David W schrieb:

Das Problem ist das dass Switch innerhalb der schleife ist. Spätestens sobald nur maximal 3x gefragt werden soll fummelt man da mit Variablen rum.
Das switch gehört in einer "IsValidInput" methode, die returniert true wenn ja; ansonsten false.
Das kann man dann wunderbar in einer while oder for schleife abarbeiten.

Beispielcode?

Es gibt zig varianten, die mir einfallen ohne nach zu denken währen diese:

public void ValidateInput(string input, int retries)
{
    for (int i = 0; i < retries; ++i)
    {
        if (IsValidInput(input))
        {
            Console.WriteLine("Eingabe korrekt");
            OnIsPassed();
            return;
        }
        else
            Console.WriteLine("Falsche Eingabe");
    }
    Console.WriteLine("Falsche Eingabe, das Konto wurde gesperrt");
    OnIsFailed();
}

public void ValidateInput(string input)
{
    while (!IsValidInput(input) && !_noRetry)
    {
        Console.WriteLine("Falsche Eingabe");
        OnBadTry();
    }
}

...

Sobald man kein guten Variablennamen findet stimmt was in der Struktur nicht und die Methode macht evtl auch zuviel.

hustbaer

@David W
Das ist hoffentlich nicht ein Beispiel für wie man es "gut" machen könnte ... ?
Ansonsten erklär mir mal wie du diese ValidateInput() einsetzen willst. Also für was anderes als um Verwirrung zu stiften.

hustbaer schrieb:

@David W
Das ist hoffentlich nicht ein Beispiel für wie man es "gut" machen könnte ... ?

Genau das habe ich mich auch gefragt.
Ich finde den Code schlecht, der Code im ersten Posting ist viel kürzer, hat kaum performancefressende Methodenaufrufe und ist auch ansonsten schlanker.
Außerdem ist die Methode IsValidInput() nicht definiert.
Gleiches gilt für OnIsPassed() und OnIsFailed()

asc

eingabeNochmal schrieb:

...hat kaum performancefressende Methodenaufrufe...

Ich habe in realen Anwendungsfällen noch nie erlebt das Methodenaufrufe wirklich zu Performanceproblemen geführt hätten. Mag sein das dies in Szenarien in denen Funktionen/Methoden Millionenmal in Folge aufgerufen werden relevant wird, aber ansonsten ist die Aussage nur ein schlechtes Beispiel für "Premature Optimization".

muemmel

Hi,

was spricht gegen Abbruch, Weiter, IsEnde...

Gruß Mümmel

314159265358979

muemmel schrieb:

Hi,

was spricht gegen Abbruch, Weiter, IsEnde...

Gruß Mümmel

Die Tatsache, dass Abbruch und Weiter auf Englisch break und continue heißen, welche schon 2 reservierte Schlüsselwörter sind, und IsEnde Denglisch ist.

pyhax

bool quit;
while(!quit) {
}

asc

314159265358979 schrieb:

muemmel schrieb:

...was spricht gegen Abbruch, Weiter, IsEnde...

Die Tatsache, dass Abbruch und Weiter auf Englisch break und continue heißen, welche schon 2 reservierte Schlüsselwörter sind, und IsEnde Denglisch ist.

Wie du schon in anderen Threads gelesen hast gibt es durchaus auch Gründe für deutschen (oder gar in Teilen denglischen) Code.

Bei uns zum Beispiel wäre die umständliche Suche nach englischen Fachbegriffen unnötige Zeitverschwendung. Zum einen wird wohl innerhalb der nächsten Jahre (eher Jahrzehnte) keiner eingestellt der nicht wenigstens Deutsch kann, zum zweiten schreiben wir Software ausschließlich für den deutschsprachigen Raum, zudem stammen unsere Begriffe nicht aus einem Bereich in dem eine Seite wie z.B. leo oder ähnliches eine sinnvolle Übersetzung findet. Wozu sollten wir unnötigerweise einen Übersetzer in Anspruch nehmen, oder uns Wörter zusammen glauben die so mit Sicherheit im Englischen niemand verwendet?

Eine Ausnahme von dieser Regel sind Begriffe die eigentlich nur in englisch verwendet werden (z.B. bei WPF MVVM: Model, View, ViewModel), da wird auch bei uns auf das englische zurück gegriffen, weil man dazu leichter Informationen im Netz findet. Das führt zwar zu denglischen Begriffen (z.B. KontaktView), aber das hält sich zum Glück stark in Grenzen.

Benutzt doch einfach goto. Ein Name für die Sprungmarke findet sich doch viel einfacher.

... klar!! GOTO vernichtet alle Probleme und ist der Heilsbringer schlechthin!!

muemmel

Hi,

deutsche Begriffe haben den Vorteil, dass sie besser aus dem Quelltext hervorstechen.

Gruß Mümmel

muemmel schrieb:

deutsche Begriffe haben den Vorteil, dass sie besser aus dem Quelltext hervorstechen.

Wasn quatsch... das sind variablen wie alle anderen auch und führen ausschliesslich zu denglischen Qeullcode... wems gefällt solls machen.

Ansonsten nenn die Variable nach der Funktion. Was sollen immer diese a, b, c, x3 etc. Variablen. Da versteht doch keiner worum es geht...

EXDW

eingabeNochmal schrieb:

hustbaer schrieb:

@David W
Das ist hoffentlich nicht ein Beispiel für wie man es "gut" machen könnte ... ?

Genau das habe ich mich auch gefragt.
Ich finde den Code schlecht, der Code im ersten Posting ist viel kürzer, hat kaum performancefressende Methodenaufrufe und ist auch ansonsten schlanker.
Außerdem ist die Methode IsValidInput() nicht definiert.
Gleiches gilt für OnIsPassed() und OnIsFailed()

Urprünglicher Code:

int eingabe; 
bool b; 
do{ 
  b = false, 
  liesEingabe(); 

  switch(eingabe){ 
    richtig_1:... 
    richtig_2:... 
    falsch: printf("Falsche eingabe, nochmal"); 
            b = true; 
} while (b);

Meine Variante als pendant:

while (!IsValidInput(input)) 
{ 
    Console.WriteLine("Falsche eingabe, nochmal"); 
}

mein Code ist kürzer, übersichtlicher und hält sich an das Single Responsibility Principle

Achja, und ich habe das OnIsPassed sowie OnIsFailed als Event Invocator gesetzt, dann schmeißt man die Console.WriteLine raus und kann es auch in nicht Consolen Applikationen verwenden (Die Consolen Ausgaben habe ich nur aus dem printf übernommen).
Das das switch im IsValidInput steckt muss ich extra erwähnen? Nahm an hier denkt man etwas mit. Der Ursprungscode ist auch unvollständig
Das Hauptproblem ist nunmal das eine Methode die Vailiert, erneute eingaben abfragt und zudem noch ausgaben tätigt einfach viel zu viel macht, Clean ist das bei weitem nicht mehr.

//Dazu
Ich würde sogar die Architektur in frage stellen, warum ist die Ausgabe und die Validierung in der Selben Klasse, das gehört getrennt sodass man es wiederverwenden, austauschen sowie Mocken kann.
Sowas ist doch eigentlich selbstverständlich.

eingabeNochmal schrieb:

Wie nennt ihr eine Boolean Variable, die auf Eingabe prüfen soll, ob Schleife verlassen werden soll?

BertramVonFallersleben

hustbaer

@David W

mein Code ist kürzer, übersichtlicher und hält sich an das Single Responsibility Principle

Jain. Single Responsibility ist gut, kurz und übersichtlich ist auch gut. Gegen das Auslagern der Validierungs-Funktion hab ich auch gar nichts einzuwenden.

Bloss funktioniert dein Code nicht (weil nirgends neuer Input eingelesen wird, die Schleife wird also bis zum Abbruch den selben ungültigen Input validieren), und der Name "ValidateInput" ist mMn. auch denkbar übel.

Achja, und ich habe das OnIsPassed sowie OnIsFailed als Event Invocator gesetzt, dann schmeißt man die Console.WriteLine raus und kann es auch in nicht Consolen Applikationen verwenden (Die Consolen Ausgaben habe ich nur aus dem printf übernommen).

Die OnIsPassed/OnIsFailed sind - so lange sie nicht gebraucht werden - einfach nur hoffnungslos overengineert.
Das von dir erwähnte Auslagern des Console.WriteLine() Aufrufs in einen solchen Handler macht nichts übersichtlicher (ganz im Gegenteil), und kann eigentlich nur mit "because I can" erklärt werden.

Es wird sicher Fälle geben wo sowas alles Sinn macht, aber nicht in diesem einfachen Beispiel.

//Dazu
Ich würde sogar die Architektur in frage stellen, warum ist die Ausgabe und die Validierung in der Selben Klasse, das gehört getrennt sodass man es wiederverwenden, austauschen sowie Mocken kann.
Sowas ist doch eigentlich selbstverständlich.

Nein, ist nicht selbstverständlich.
Nicht jedes Programm muss zu einem unübersichtlichen overengineerten Behemoth werden.
KISS

langeweile

break/continue