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



  • Also so etwas:

    Pseudocode

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

    Wie benennt ihr hier b?



  • liesEingabe liefert natürlich was zurück.

    korrigierte Version:

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


  • Für "true = weiterlaufen" z.B. "run".
    In deinem Fall vielleicht "repeat_input" oder "invalid_input".

    Da bei dir das Weiterlaufen aber eher die Ausnahme ist, solltest du die Logik vielleicht umdrehen, also "true = fertig".
    Dann könntest du "have_valid_input" als Name verwenden.

    int input = 0;
    bool have_valid_input = false;
    
    while (!have_valid_input)
    {
        input = ...;
        switch (...)
        {
        ...:
            have_valid_input = true;
            break;
        }
    }
    


  • Variablen, die nur für den Programmfluss notwendig sind und auch nur in einem begrenzten Kontext gültig sind, haben bei mir meist nur einen Buchstaben. b ist hier nicht anders als i in for-Schleifen



  • Finde ich nicht gut - brauch ich garantiert länger beim Lesen bis ich sehe was gemeint ist als wenn das Ding nen guten Namen hat.

    Bei "i" als Schleifenvariable ist mehr-oder-weniger klar was gemacht wird: man geht vorwärts oder rückwärts über eine bestimmte Range. Noch dazu hat man typischerweise ne "for" Schleife, da sieht man gleich im Schleifenkopf was wirklich gemacht wird (welche Range, welche Richtung, welche Schrittweite etc.).

    Bei "b" als "Kontrollvariable" ist überhaupt nichts klar, d.h. ich muss erstmal nachgucken was das Ding tut => finde ich nicht gut.



  • hustbaer schrieb:

    Bei "b" als "Kontrollvariable" ist überhaupt nichts klar, d.h. ich muss erstmal nachgucken was das Ding tut => finde ich nicht gut.

    nicht bei jeder Variable muss ich auf dem ersten Blick wissen, was sie macht.
    Andersrum weiß ich bei solchen Variablen aber auch auf dem ersten Blick, dass sie nur für die aktuelle Kontrollstruktur eine Relevanz haben



  • Umso kuerzer der Variablenname, desto kleiner ihr scope ... und andersherum.



  • zwutz schrieb:

    nicht bei jeder Variable muss ich auf dem ersten Blick wissen, was sie macht.

    Sofern man nur für sich programmiert würde ich das ja noch akzeptieren. In einem Projekt mit mehreren Entwicklern halte ich diese Aussage für mehr als nur Grenzwertig.



  • Ne, nichtmal sofern man nur für sich programmiert.

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



  • 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.



  • 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?



  • bool b = true;
    while (b) {
    
       /* ... */
    
       if (/* Abbruchbedingung */)
          b = false;
    
    }
    

    finde ich bei kleineren Strukturen durchaus ausreichend. Klar, wenn die Schleife ein 200-Zeilen-Monster ist, dann sollte man sich was überlegen, aber bei sowas (also wenn kaum Code zwischen Instanzierung und Verwendung ist) mach ich mir wirklich nicht die Mühe.

    Deswegen zieh ich sie ja nicht gleich durchs ganze Programm

    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)



  • 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.


  • Mod

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



  • 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 😉



  • 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".



  • 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.



  • @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()



  • 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".



  • Hi,

    was spricht gegen Abbruch, Weiter, IsEnde...

    Gruß Mümmel


Anmelden zum Antworten