Meine liebe Hassliste

cooky451

Ich mag if ( lieber?

Eisflamme

Also ich finde, ich hab schön argumentiert mit meinem Vergleich zu Funktionen, bei denen das Leerzeichen ja auch komisch aussieht. Ich präferiere if( und habe meinen Standpunkt auch unterlegt. :p

Antoras

Eisflamme schrieb:

Hat keiner Argumente für if ( statt if(?

Ich mag if ( lieber, da das if, als Schlüsselwort, speziell vom Editor gekennzeichnet wird. Es unterscheidet sich also von einem normalen Funktionsaufruf. Außerdem erwartet if nicht nur eine Parameterliste, sondern ganze zwei, da sieht das nicht mehr wohlgeformt aus wenn man es in typischer Objektsyntax schreiben würde: if(cond)(block1).else(block2)

Ich mag daher Programmiersprachen, die ein then Schlüsselwort haben, da kann man dann if ... then ... else ... schreiben ohne irgendwelche Klammern.

Kellerautomat schrieb:

Spaces zum Einruecken missbraucht. Machen nur Leute, die den Unterschied zwischen einruecken und ausrichten nicht verstanden haben.

Oder Leute, die manuelles Ausrichten hässlich finden (bzw. sogar ganz ablehnen) und sowieso immer spaces verwenden.

Nathan

#include <iostream>
#define if if(
#define then )
int main()
{
    if true then
        std::cout << "foo";
}

Wenn dus so gerne magst...

GyroGearloose

Eisflamme schrieb:

Also ich finde, ich hab schön argumentiert mit meinem Vergleich zu Funktionen, bei denen das Leerzeichen ja auch komisch aussieht.

Ja, deine Argumentation ist nachvollziehbar und auch schwer anfechtbar, wenn man ebenfalls kein Leerzeichen bei Funktionen schreibt.

Ich schreibe allerdings trotzdem ein Leerzeichen nach if/for/while. Wie Antoras schon sagte, gehören zu einem if eben nicht nur die "Parameterliste", sondern auch der Anweisungsblock und ggf. ein else mit einem weiteren Anweisungsblock. Bei einem vollständigen if würde man dann etwa folgendes schreiben:

if (x < 0)
{
	Foo();
	Bar();
}
else
{
	Bar();
	Foo();
}

Bzw. in der anderen {}-Geschmacksrichtung:

if (x < 0) {
	Foo();
	Bar();
} else {
	Bar();
	Foo();
}

Wie man sieht, sind die Blöcke und das else ebenfalls durch Whitespaces (Leerzeichen, Zeilenumbrüche) abgehoben. Würde ich das Leerzeichen nach dem if weglassen, wäre es zusamen mit der Bedingung - meiner Meinung nach - vom Rest abgetrennter. Ich müsste also konsequenterweise, um die if ... then ... else ... -Ebene zu erhalten, etwa folgendes schreiben, wobei es aufgrund der unumstrittenen Zeilenumbrüche und Einrückungen immer noch "geclustert" aussieht:

if(x < 0){
	Foo();
	Bar();
}else{
	Bar();
	Foo();
}

Deswegen schreibe ich ein Leerzeichen nach dem if, damit das Gesamtkonstrukt "einheitlich luftig" aussieht und nicht "partiell verklumpt".
Aus demselben Grund bevorzuge ich übrigens auch die geschweiften Klammern am Zeilenanfang, da Blöcke sonst unterbrochen wirken, wenn man Leerzeilen zur Strukturierung verwendet.

Aber naja... ich glaube das Leerzeichen nach dem if ist noch das kleinste Problem und tatsächlich eine Geschmacksfrage, wie man an meiner krampfhaften und blumigen Begründung erkennt.

Antoras schrieb:

Außerdem erwartet if nicht nur eine Parameterliste, sondern ganze zwei, da sieht das nicht mehr wohlgeformt aus wenn man es in typischer Objektsyntax schreiben würde: if(cond)(block1).else(block2)

Zwei Parameterlisten? Unfug!

if(status){
  block1;
} else {
  block2:
}

Und die Blöcke werden übrigens in geschweifte Klammern gesetzt.

Ich mag daher Programmiersprachen, die ein then Schlüsselwort haben, da kann man dann if ... then ... else ... schreiben ohne irgendwelche Klammern.

Und damit wird jedem Editor in den Arsch getreten, der Klammerblöcke zusammenfalten kann.
Die Übersicht wird dann ebenfalls schlechter.

Fazit:
Ich bevorzuge Klammern.

GyroGearloose schrieb:

Bzw. in der anderen {}-Geschmacksrichtung:
if (x < 0) {
	Foo();
	Bar();
} else {
	Bar();
	Foo();
}
Wie man sieht, sind die Blöcke und das else ebenfalls durch Whitespaces (Leerzeichen, Zeilenumbrüche) abgehoben. Würde ich das Leerzeichen nach dem if weglassen, wäre es zusamen mit der Bedingung - meiner Meinung nach - vom Rest abgetrennter. Ich müsste also konsequenterweise, um die if ... then ... else ... -Ebene zu erhalten, etwa folgendes schreiben, wobei es aufgrund der unumstrittenen Zeilenumbrüche und Einrückungen immer noch "geclustert" aussieht:
if(x < 0){
	Foo();
	Bar();
}else{
	Bar();
	Foo();
}

Vor dem else gehört IMMER ein Leerzeichen, weil das bei normalem Text auch üblich ist, dass man nach einem Satzzeichen ein Leerzeichen verwendet:

Der rote Baum spricht. Fritz hört zu. // richtig

Der rote Baum spricht . Fritz hört zu . // falsch, da Plenken

Der rote Baum spricht .Fritz hört zu . // falsch, da Plenken und fehlendes Leerzeichen vor Fritz.

Der rote Baum spricht.Fritz hört zu. // Falsch, da fehlendes Leerzeichen vor Fritz

daraus folgt:

if(status){
  block1;
} else{ // Vor dem else muss ein Leerzeichen kommen und nach dem else darf keines kommen, gleiches gilt daher auch für if. Das if ist wie vor dem Punkt beim Satzende, deswegen darf da kein Leerzeichen zwischen if und Klammer stehen. 
  block2;
}

Deswegen schreibe ich ein Leerzeichen nach dem if, damit das Gesamtkonstrukt "einheitlich luftig" aussieht und nicht "partiell verklumpt".

Beim Satzende darf zwischen letztem Wort und dem abschließenden Punkt kein Leerzeichen stehen, deswegen darf das bei einem if auch nicht der Fall sein.

GyroGearloose

Programmierfachprofi schrieb:

Beim Satzende darf zwischen letztem Wort und dem abschließenden Punkt kein Leerzeichen stehen, deswegen darf das bei einem if auch nicht der Fall sein.

Das stimmt. Allerdings gilt das doch nicht für Klammern (wie man an diesem Einschub sieht). Bei Kommata in Parameterlisten aber auf jeden Fall. Und was ist mit dem Punkt-Operator bei Objekten? Der wäre dann doch auch ein Satzzeichen... Oder der ternäre bedingte Operator:

int x = y < 0? 1: 0;

Das sieht doch auch seltsam aus, oder? Das heißt, ich glaube nicht, dass man die Regelungen aus der natürlichen Sprache auf Programmiersprachen vollständig übertragen kann.

volkard

Warum nicht gleich

if	(x < 0) {
	Foo();
	Bar();
}	else {
	Bar();
	Foo();
}

?
Jetzt stehen alle Wichtigen Sachen untereinander, wo man sie schnell findet.

Antoras

Programmierfachprofi schrieb:

Und die Blöcke werden übrigens in geschweifte Klammern gesetzt.

Nicht wenn man Schlüsselwörter mit Funktionen vergleicht, die mit runden Klammern aufgerufen werden müssen.

Programmierfachprofi schrieb:

Ich mag daher Programmiersprachen, die ein then Schlüsselwort haben, da kann man dann if ... then ... else ... schreiben ohne irgendwelche Klammern.

Und damit wird jedem Editor in den Arsch getreten, der Klammerblöcke zusammenfalten kann.
Die Übersicht wird dann ebenfalls schlechter.

Mit Klammern meinte ich die runden Klammern zwischen if und then, die können weggelassen werden, da da in der Regel nur eine Anweisung steht. Zwischen then und else bzw. nach dem else müssen natürlich weiterhin geschweifte Klammern gesetzt werden wenn mehrere Anweisungen kommen, sonst kann der Compiler das Ende nicht finden (oder halt zwingende Einrückungen zur Blockabtrennung benutzen). Beides arbeitet ohne Probleme mit Folding zusammen.

Beim Satzende darf zwischen letztem Wort und dem abschließenden Punkt kein Leerzeichen stehen, deswegen darf das bei einem if auch nicht der Fall sein.

Nach dem if kommt aber kein Punkt, sondern ein paar Klammern, genau genommen sogar zwei:

Ich (bin) ein (Satz) (mit Anhang).