3. if und else passen nicht zueinander ?

if und else passen nicht zueinander ?

  • S

    Hab jetzt diese Klammern gesetzt ,zudem habe ich noch eine Schleife eingebaut. Funktioniert allerdings nicht.

    #include <iostream>
#include <cmath>

int main()    {

	while(true) { 
		std::cout << "Rechnen ?" << std::flush;
		double rechnen = 0.0;
		std::cin >> rechnen;

		if(rechnen==1)   {
			std::cout<< "zahl:" << std::flush;
			double zahl = 0.0;
			std::cin >> zahl;

			std::cout<< "exp:" << std::flush;
			double exp = 0.0;
			std::cin >> exp;

			std::cout<< "Das Ergebnis von " << zahl << " * " << exp << " ist: " << pow(zahl,exp) << std::flush;
		}
		else(rechnen==0)    {

			break;
			}
		}
   }
    0
  • C

    "else" hat (und braucht) keine eigene Bedingung - d.h. der Teil "(rechnen==0)" ist falsch.

    PS: Vielleicht solltest du mal ein Buch konsultieren, um wenigstens die grundlegenden Kontrollstrukturen von C++ zu verstehen. Und vielleicht solltest du auf deinen Compiler hören, der sagt normalerweise mehr als "das Programm ist falsch" 😉

    0
  • K

    das mit immer klammern setzen ist wirklich quatsch, denn man setzt ja auch nicht nach einem else eine klammer, wenn direkt danach ein if folgt, das wäre einfach nur schwachsinnig und unübersichtlich, und thordk es hilft viel mehr die Sprache zu verstehen, wenn man weiß, wo man klammern setzten muss, und wo nicht.

    0
  • T

    die meinung kann ich nicht teilen. abkürzungen sollte man erst nutzen, wenn man absolut sicher mit etwas umgehen kann. und "überflüssige" klammerung, wie ihr es wohl seht, ist ein mittel, das für verständlicheren code sorgt.

    if(foo == 17)
 if(bar == 12)
  baz();
 else
  bay();
else
 bax();
baw();

    sieht übersichtlich aus. jetzt ist der coder bisschen schlampig

    if(foo == 17)
 if(bar == 12) baz(); 
else
 bay();
 else
  bax(); baw();

    sieht auf den ersten blick seltsam aus und man muss nochmal hingucken

    if(foo == 17)
{
 if(bar == 12){ baz(); }
else{
 bay();
}}
 else
{
  bax();} baw();

    sieht auch mistig aus, aber man kann sich problemlos an den klammern entlanghangeln, um den kontrollfluss zu sehen. ausserdem kann man sehr sicher sein, dass es genau so gemeint ist, wie es da steht.

    0
  • X

    Also ich find schon,dass es mit den geschweiften Klammern einfacher zu merken ist, als ohne.

    Besonders bei else if's vertut man sich häufig, wenn man keine Klammern macht.

    if(tuwas)
{
//..
} else if(xxx)
{
//...
} else if(xxx)
{
//.....
} else {
//...
}
    0
  • K

    Hi thordk,

    Dein Code beweist zwei Dinge (mal davon abgesehen, dass der Beweis durch Beispiel nicht gilt):

    - Ordentliche (also auch ordentlich "weite") Einrückung hilft
    - Verschachtelte 'if's mit dem sogenannten Dangling-'else' sind ein Problem

    ... aber er beweist erstmal nicht, dass die Klammern vonnöten sind. Wobei ich in diesem Spezialfall Deine Meinung teile: Das Dangling-Else bereitet so vielen Leuten Probleme, dass es hier wirklich von Vorteil wäre, zumindest den äußeren If-Block zu klammern.

    Übrigens geht es mir persönlich so, dass ich beim Analysieren eines Programmis *nicht* auf die Klammerung sondern allein auf die Einrückung achte. Fazit: mit fehlerhafter Einrückung kann man nicht erfolgreich verwirren. Sicherlich wäre es theoretisch sinnvoller, sich *nicht* an der (eventuell falschen) Einrückung zu orientieren aber es ist nunmal viel einfacher und daher werde ich es auch weiterhin tun (wobei ich das eh automatisch mache und da gar keinen großen Einfluss drauf habe).

    0
  • K

    XP^ schrieb:

    Also ich find schon,dass es mit den geschweiften Klammern einfacher zu merken ist, als ohne.

    Besonders bei else if's vertut man sich häufig, wenn man keine Klammern macht.

    if(tuwas)
{
//..
} else if(xxx)
{
//...
} else if(xxx)
{
//.....
} else {
//...
}

    mit allen Klammern richtig geschachtelt sähe das wie folgt aus:

    if(tuwas){
//..
}else{
    if(xxx){
    //...
    }else{
        if(xxx){
        //.....
        }else {
            //...
        }
    }
}

    und das kann man beim besten Willen nicht übersichtlich nennen, da lässt man dann lieber Klammer samt Einrückung aus.
    ja und "else if's" gibs nicht, es ist ersten nur eine besondere Form der if else Zweige (ein if folgt einem else), und zum anderen benutzt man im Deutschen kein ' für Pluralbildung.

    0
  • T

    und was genau ist daran nicht übersichtlich?

    das ganze hat zudem noch nen tollen nebeneffekt: wenn man korrekt klammert und einrückt und dadurch irgendwann 20 tabs vor seinem nächsten else einfügen "muss", dann sieht man sehr schnell ein, dass man das ganze gedöns wohl doch lieber nochmal überdenken und eleganter gestalten sollte.

    0
  • ?

    Krux schrieb:

    mit allen Klammern richtig geschachtelt sähe das wie folgt aus:

    if(tuwas){
//..
}else{
    if(xxx){
    //...
    }else{
            if(xxx){
        //.....
        }else {
            //...
            }
    }
}

    und das kann man beim besten Willen nicht übersichtlich nennen, da lässt man dann lieber Klammer samt Einrückung aus.

    ...

    Das ist allerdings nicht übersichtlich, wenn man das so seltsam hinfriemelt.
    Lieber etwas mehr Luft für den Quelltext lassen, auch wenn es ein paar Zeilen mehr werden.
    Es verbessert deutlich die Lesbarkeit für einen selbst und für andere:

    if(tuwas)
{
	//..
}
else
{
	if(xxx)
	{
		//...
	}
	else
	{
        if(xxxx)
        {
            //.....
        }
        else
        {
            //...
        }    
	}
} // tuwas

    Man sieht sofort, welches else zu welchem if gehört.

    In der Praxis kommt es durchaus vor, das sich verschachtelte if-else Bedingungen über mehrere Bildschirmhöhen erstrecken. Von daher sind geegnete Kommentare im Quelltext, welche die Zugehörigkeit der if-else- Paare leichter erkennen lassen, durchaus sinnvoll.

    thordk schrieb:

    man sollte sich einfach angewöhnen, die anweisungen nach if und else statements IMMER in klammern zu packen, auch wenns nur eine zeile ist. beugt genau solchen fehlern vor.

    Diese Aussage möchte ich mit folgender Begründung bestätigen:
    Auch wenn der else-Teil nur aus einer Anweisung besteht, diese kann sich über mehrere Zeilen erstrecken.
    Für das Nachvollziehen eines Quelltextes und für die Fehlersuche ist es logischerweise viel einfacher, wenn diese in einem Klammernblock übersichtlich angeordnet ist.
    Im übrigen lernt man so etwas an jeder besseren Schule, weil es Resultate aus umfangreichen Studien sind, die sich mit der Lesbarkeit, Wartung, Fehlerhäufigkeit von Quelltexten beschäftigt hatten.

    MfG
    D. K.

    0
  • O

    wie sagte man mir damals so treffend? bei einer funktion mit mehr als 3 einrückungen macht man entweder was falsch, oder man kann mindestens eine teilfunktion auslagern.

    0
  • T

    Also ich habe mir angewöhnt, bei einzeilern keine Klammern zu benutzen. Falls dann aber ein if folgt, benutze ich die klammern.
    Auch wenn auf ein einzeiliges if ein mehrzeiliges else folgt, setze ich bei beiden die Klammern.

    Damit hatte ich bisher nie probleme, und ich finde es auch ganz angenehm zu lesen.

    0
  • D

    The-Kenny schrieb:

    Also ich habe mir angewöhnt, bei einzeilern keine Klammern zu benutzen.

    Mach ich genauso:

    if (!some_pointer) return;

    vs.

    if(!some_pointer)
{
    return;
}

    Am besten wenns dann mehrere Abfragen ähnlicher Art in Reihe sind ist die erste Methode IMHO übersichtlicher

    0
Anmelden zum Antworten