Ist das sauber geschrieben?

[Gohan]

Hi, wollte nur mal wissen, ob meine Infomatik Hausaufgabe eurer Meinung nach sauber geschrieben ist. Aufgabe war es, einen Schaltjahr Prüfer zu programmieren. (Ist das Jahr glatt durch 4 Teilbar, aber nicht durch 100 = Schaltjahr oder durch 400 = Schaltjahr)


#include <iomanip.h>
#include <stdio.h>

int main ()
{
int jahr;
cout << "Willkommen zum Schaltjahrpruefer" << endl;
cout << "================================" << endl << endl;
cout <<"Bitte geben Sie das zu pruefende Jahr ein: "; cin >> jahr;
cout << endl << endl;

if (0 == jahr % 4 && 0 != jahr % 100 || 0 == jahr % 400)
cout << "Wir haben ein Schaltjahr.";
else
cout << "Wir haben kein Schaltjahr.";
return 0;
}


Es ist ein ganz kleiner Code und es funktioniert, aber ist diese if Anweisung wirklich gut?

[Coda]

Das kompiliert so nichtmal auf einem standardkonformen Compiler.

[Armaq]

Warum hilfst du ihn dann nichtmal? Der arme wird von dir nur abgefertig :D

[maodi]

also mit em borland builder geht das...

und die if anweisung ist auch so richtig... jedenfalls habe ich das auch so gelernt bekommen^^

[Coda]

Der Borland Builder ist auch kein Compiler sondern ne Krankheit.

#include <iostream>

int main()
{
using namespace std;

int jahr;
cout << "Willkommen zum Schaltjahrpruefer" << endl;
cout << "================================" << endl << endl;
cout << "Bitte geben Sie das zu pruefende Jahr ein: ";
cin >> jahr;
cout << endl << endl;

if (0 == jahr % 4 && 0 != jahr % 100 || 0 == jahr % 400)
cout << "Wir haben ein Schaltjahr.";
else
cout << "Wir haben kein Schaltjahr.";
}

[noid]

mal von "nicht standard-blabla" abgesehen, ist folgendes "schlecht":
- formatierung (mach klammern bub!), einrücken.
- 3 Ausdrücke, die mit und und oder verknüpft sind -> seltsam, macht man imho so nicht.

[Gohan]

- 3 Ausdrücke, die mit und und oder verknüpft sind -> seltsam, macht man imho so nicht.

Habs ja anders versucht, aber das war mir irgendwie die einzigste Lösung die mir in den Sinn kam.

P.S.
XCode kompiliert das ganze, ebenso Dev-C++. Wofür ist dieses using namespace std; gut?


#include <iostream>

int main ()
{
using namespace std;
int jahr;
cout << "Willkommen zum Schaltjahrpruefer" << endl;
cout << "================================" << endl << endl;
cout <<"Bitte geben Sie das zu pruefende Jahr ein: ";
cin >> jahr;
cout << endl << endl;

if (0 == jahr % 4 && 0 != jahr % 100 || 0 == jahr % 400)
cout << "Wir haben ein Schaltjahr.";
else
cout << "Wir haben kein Schaltjahr.";
return 0;
}

[Marscel]

P.S.
XCode kompiliert das ganze, ebenso Dev-C++. Wofür ist dieses using namespace std; gut?

Wofür es gut ist? Du musst somit nicht std::count oder std::cin schreiben, sondern trittst in das/den Namespace für den Rest des Scopes ein.

[maodi]

- 3 Ausdrücke, die mit und und oder verknüpft sind -> seltsam, macht man imho so nicht.

warum soll das seltsam sein besser als zwei if s raus zumachen ;D

[SamStone]

Habs ja anders versucht, aber das war mir irgendwie die einzigste Lösung die mir in den Sinn kam.
Das doofe daran ist, das das Uneindeutig sein kann (für den Menschen), je nachdem ob der Compiler dem && oder dem || den VOrrang gibt. Deswegen setz am besten passende Klammer darum.

[Coda]

Das ist standarisiert. && hat eine höhere Priorität als ||. Das wird sonst aber auch überall so gehandhabt.

http://www.cppreference.com/operator_precedence.html

Das "return 0;" in der main kann man übrigens weglassen, das wird implizit vom Compiler eingefügt.

[Xmas]

Trotzdem sollte man klammern, mindestens mal die logisch verknüpften Ausdrücke selbst. Liest sich einfach besser. Außerdem, auch wenn einige Coding Styles vorschlagen den konstanten Ausdruck (wenn vorhanden) nach links zu setzen, weil man damit =/== Fehler vermeidet, sollte man IMO der Lesbarkeit den Vorrang geben, und da erwartet man in der Regel dass der konstante Ausdruck rechts steht. Zuweisungen in der if-Bedingung hätte man von Anfang an verbieten sollen, die bringen nichts als Ärger und schwer verständlichen Code.
Ob man Vergleiche mit Null dann durch ! ersetzt bzw. gleich ganz weglässt, ist Geschmackssache, hier würde ich es eher nicht tun. Bei Python tue ich das in der Regel, weil es noch andere Probleme abfängt. Aber Python ist sowieso lesbarer als C++.

if ((jahr % 4 == 0) && (jahr % 100 != 0) ||
(jahr % 400 == 0))

[Abe Ghiran]

Man könnte auch noch weiter gehen und eine kleine Funktion

bool isLeapYear(int year){
...
}

schreiben, das macht den if Ausdruck für einen Menschen noch einfacher zu verstehen:

if(isLeapYear(year))

Spätestens wenn man den gleichen logischen Ausdruck an mehr als einer Stelle in einem Programm braucht, führt daran meiner Meinung nach kein Weg vorbei. Sonst hat man beim warten des Codes ein echtes Problem, wenn sich die Bedingung mal ändern sollte.

Grüße, Jan

[clm[k1]]

Ich würde auch prinzipiell den Code einer if-Bedingung in geschweifte Klammern setzten - auch wenn es nur eine Zeile ist!

Erhöht IMO die Lesbarkeit, vor allem aber beugt es Fehlern vor, falls man daraus mal mehr als eine Zeile macht!


clm[k1]

[Coda]

Gewohnheit. Ich mach das auch nie und hatte noch nie nen Fehler in dem Zusammenhang an den ich mich noch erinnern könnte.

[muhkuh_rs]

Gewohnheit. Ich mach das auch nie und hatte noch nie nen Fehler in dem Zusammenhang an den ich mich noch erinnern könnte.
Naja, nur wenn mal jemand anderes Deinen Code dann lesen muss, dann brauchst Du Dich nicht zu wundern, wenn er Dich auf einmal nicht mehr grüßt ;)

[Coda]

Wieso? Ich seh das öfters auch in anderem Code. Beispiel:

if(tok.begin() == tok.end()) return;vs.
if(tok.begin() == tok.end()) {
return;
}Sorry, aber da is mir das zweite einfach zu dumm. Bei so Einzeilern finde ich die Klammer einfach nur überflüssig und macht nur den Code fetter.

Das gleiche gilt für delete-loops, z.B.
for(unsigned int i=0;i<256;++i)
delete char_infos[i];Wär mir viel zu blöd da Klammern zu machen. Aber bitte ist jedem seine Sache...

[SamStone]

Das ist standarisiert. && hat eine höhere Priorität als ||. Das wird sonst aber auch überall so gehandhabt.
Deswegen schrieb ich ja "für den Menschen".

']Ich würde auch prinzipiell den Code einer if-Bedingung in geschweifte Klammern setzten - auch wenn es nur eine Zeile ist!

Erhöht IMO die Lesbarkeit, vor allem aber beugt es Fehlern vor, falls man daraus mal mehr als eine Zeile macht!
Finde ich überhaupt nicht.

[muhkuh_rs]

Wieso? Ich seh das öfters auch in anderem Code. Beispiel:

if(tok.begin() == tok.end()) return;vs.
if(tok.begin() == tok.end()) {
return;
}Sorry, aber da is mir das zweite einfach zu dumm. Bei so Einzeilern finde ich die Klammer einfach nur überflüssig und macht nur den Code fetter.

Das gleiche gilt für delete-loops, z.B.
for(unsigned int i=0;i<256;++i)
delete char_infos[i];Wär mir viel zu blöd da Klammern zu machen. Aber bitte ist jedem seine Sache...

Missverständnis. Dabei setze ich auch keine Klammern. Aber so was ist echt ne Zumutung:

if (0 == jahr % 4 && 0 != jahr % 100 || 0 == jahr % 400)

[Coda]

Ja, da würde ich wohl auch Klammern setzen.

[Wanginator]

if ((0 == jahr % 4 && 0 != jahr % 100) || 0 == jahr % 400)

finde es andersrum schöner (und verständlicher):

if ((jahr % 4 == 0 && jahr % 100 != 0) || jahr % 400 == 0)

[Coda]

das "0 ==" machen welche, weil man dann nicht aus versehen "0 =" schreiben kann. Ist ganz in Ordnung für Anfänger.

[ScottManDeath]

das "0 ==" machen welche, weil man dann nicht aus versehen "0 =" schreiben kann. Ist ganz in Ordnung für Anfänger.

Nicht nur für Anfänger ;) Wobei andere Sprachen, wie z.B. Java und C# kein impliziertes casten von int nach bool haben, so dass a = 7 einen Compilerfehler erzeugt.

[Xmas]

Und wiederum andere Sprachen haben zwar einen impliziten "Cast" der if-Bedingung nach bool, lassen aber keine Zuweisung darin zu. Der bessere Weg, wie ich finde.

[Gast]

Meine Planung sieht vor, dass eine Zuweisung keine "Expression" ist, sondern ein "Statement", ergo hat eine Zuweisung keinen Wert der sich zB für eine if-Bedingung eignen würde, cast oder nicht cast ist damit auch egal.

-zecki

[ScottManDeath]

Meine Planung sieht vor, dass eine Zuweisung keine "Expression" ist, sondern ein "Statement", ergo hat eine Zuweisung keinen Wert der sich zB für eine if-Bedingung eignen würde, cast oder nicht cast ist damit auch egal.

-zecki
Hehe ja ;)

Dann verbietest Du aber auch (unbewusst?)

a = b = c;

(Was ich persönlich schlechten Stil finde)

[zeckensack]

Hehe ja ;)

Dann verbietest Du aber auch (unbewusst?)

a = b = c;

(Was ich persönlich schlechten Stil finde)Bewusst. Das halte ich für ganz schlechten Stil.

[Xmas]

Meine Planung sieht vor, dass eine Zuweisung keine "Expression" ist, sondern ein "Statement", ergo hat eine Zuweisung keinen Wert der sich zB für eine if-Bedingung eignen würde, cast oder nicht cast ist damit auch egal.

-zecki
Deine Planung scheint sich in diesem Punkt mit meiner Planung zu decken... ;)

[Bietchiebatchie]

Was plant ihr denn bitte?
Eigene Programmiersprache?