bei ternär, wenn das 'else' unnötig ist

[han]

Hi,

was ist die Beste Möglichkeit, beim ternären Operator dem 'else' keine Funktion zukommen zu lassen? Weglassen darf man es ja nicht...

also ich mach das bisjetzt so_:
(bedingung ? dies : '');

sind die '' eine gute Lösung für nichts?

gruß

[Der Martin]

Hallo,

was ist die Beste Möglichkeit, beim ternären Operator dem 'else' keine Funktion zukommen zu lassen? Weglassen darf man es ja nicht...

nein, aber man sollte dort einen Ersatzwert haben, für den Fall dass die Bedingung nicht zutrifft.

(bedingung ? dies : '');
sind die '' eine gute Lösung für nichts?

Ebensogut wie jede andere Konstante. Aber wenn du das Ergebnis des Ausdrucks sowieso nicht verwendest, spricht eigentlich nichts für den Fragezeichen-Operator. Dann würde ich lieber ein herkömmliches if-Statement verwenden.

Ciao,
 Martin

[Marcel]

Hallo,

der ternaere Operator ist dafuer da, um eine If-Else-Anweisung
zu vereinfachen. Wenn Du jetzt allerdings ein IF ohne Else
verwenden moechtest, so macht die Verwendung dieses Operators
wenig Sinn.

if(bedingung)
   DoSth();

Marcel

[han]

Hallo,

ist es eigtl nur eine Schöhnheitssahce, ob ich bei einer if-Abfrage mit nur einer Zaiel danach die eckigen Klammern weglasse?

gruß

[Marcel]

Hallo,

ist es eigtl nur eine Schöhnheitssahce, ob ich bei einer if-Abfrage mit nur einer Zaiel danach die eckigen Klammern weglasse?

Wenn Du mit "eckig" "geschweift" meinst, dann: Ja!

Marcel

[Sven Rautenberg]

Moin!

Hallo,

ist es eigtl nur eine Schöhnheitssahce, ob ich bei einer if-Abfrage mit nur einer Zaiel danach die eckigen Klammern weglasse?
Wenn Du mit "eckig" "geschweift" meinst, dann: Ja!

Nein!

Geschweifte Klammern kann man genau dann weglassen, wenn nur eine einzige nachfolgende Anweisung zu diesem IF gehört.

Aber man sollte sie nicht weglassen. Denn fügt man eine zweite Anweisung hinzu, die auch innerhalb vom IF ausgeführt werden soll, benötigt man die Klammern wieder.

Wenn kein ELSE nachfolgt, ist aber folgendes ein gültiges Skript:

  
if (wasauchimmer == false)  
  mache_irgendwas();  
  und_neu_jetzt_auch_das();  

Mit dem Unterschied: Die zweite Anweisung wird IMMER ausgeführt, auch wenn sie hier so schön eingerückt dasteht.

Deshalb: Um Fehler zu vermeiden, sollte man GRUNDSÄTZLICH KLAMMERN SETZEN, egal wieviele Anweisungen im IF stehen. Vergessene Klammern fallen einem nämlich nicht sofort ins Auge, wenn man "mal so, mal so" schreibt.

Schreibt man IF hingegen IMMER mit Klammern, fällt einem ein IF ohne Klammern sofort auf.

- Sven Rautenberg

[Marcel]

Hallo Sven,

ist es eigtl nur eine Schöhnheitssahce, ob ich bei einer if-Abfrage mit nur einer Zaiel danach die eckigen Klammern weglasse?
Wenn Du mit "eckig" "geschweift" meinst, dann: Ja!
Nein!

Doch.

Geschweifte Klammern kann man genau dann weglassen, wenn nur eine einzige nachfolgende Anweisung zu diesem IF gehört.

Eben! Und darum ging es im obigen Beispiel.

Also ich werde mir weiterhin - trotz deines wehementen Belehrungszwanges -
die Klammern bei einer einzeiligen If-Anweisung sparen.
So einfach ist das!

Marcel

[Der Martin]

Hallo Marcel,

Geschweifte Klammern kann man genau dann weglassen, wenn nur eine einzige nachfolgende Anweisung zu diesem IF gehört.
Eben! Und darum ging es im obigen Beispiel.
Also ich werde mir weiterhin - trotz deines wehementen Belehrungszwanges - die Klammern bei einer einzeiligen If-Anweisung sparen.

beachte bitte: EINE Zeile != EINE Anweisung. Folgendes Statement ist syntaktisch auch korrekt, aber visuell sehr irreführend:

~~~php if ($x>4)
    foo($x); bar($x);

  

> So einfach ist das!  
  
Ja, wenn du dir selbst Fallstricke legen willst, bitte sehr.  
  
So long,  
 Martin  

-- 
Success should be measured not so much by the position that one has reached in life,  
but by the obstacles one has overcome while trying to succeed.

[Marcel]

Hallo,

Ja, wenn du dir selbst Fallstricke legen willst, bitte sehr.

Dass hier immer Leute meinen, besser ueber das bescheid zu wissen,
was ein anderer tut, ist wirklich bemerkenswert.
Also, ich weiß ja nicht, wie das bei dir so aussieht, aber ich
meinerseits habe seit ueber 20 Jahren keine Probleme auf Grund der
von mir verwendeten Schreibweise gehabt - weder ich, noch meine
Mitarbeiter.
Aber hauptsache den Mund aufmachen.. ist schon klar.

Marcel

[globe]

n'abend,

Ja, wenn du dir selbst Fallstricke legen willst, bitte sehr.
Dass hier immer Leute meinen, besser ueber das bescheid zu wissen,
was ein anderer tut, ist wirklich bemerkenswert.

versuchen die Antworten möglicherweise lediglich ihre (in diesem Fall wohl eher negativen) Erfahrungen mit dem Thema zu erläutern und den Lesenden darauf hinzuweisen, dass er möglicherweise auftretende Probleme von vornherein vermeiden kann?

Also, ich weiß ja nicht, wie das bei dir so aussieht, aber ich
meinerseits habe seit ueber 20 Jahren keine Probleme auf Grund der
von mir verwendeten Schreibweise gehabt - weder ich, noch meine
Mitarbeiter.

Stehen dein Alter und der Grad deiner Erfahrung in diesem Bereich fett auf deiner Stirn geschrieben? Ist es den Antwortenden möglich diese Stirn zu sehen?

Ist es vielleicht möglich, dass du dich persönlich angegriffen fühlst, weil du einen anderen Stil bevorzugst, als der Rest der Anwesenden? Ist dieses Verhalten (in deinem geschätzten, etwas höheren) Alter notwendig?

Manchmal habe ich das Gefühl, dass viele hier einfach zu gefühlsduselig an die Sache rangehen, sich deshalb umgehend angegriffen fühlen und "zu diesem Forum"-Threads starten müssen. Sachlich ist das hier irgendwie nicht mehr.

P.S.: Falls es dich beruhigt, du stehst nicht alleine da. Auch meinereiner nutzt die klammerlose Notation, wenn abzusehen ist, dass da nichts mehr hinzukommt.

weiterhin schönen abend...

[Sven Rautenberg]

Moin!

Du echauffierst dich vollkommen unnötig.

ist es eigtl nur eine Schöhnheitssahce?
Ja!
Nein!

Meine Begründung hast du gelesen.

Doch.

Beharrst aber trotzdem auf deinem Standpunkt. Sei dir unbenommen.

Programmieren besteht aber nicht nur aus dem, was technisch möglich ist, sondern besteht auch aus einer menschlichen Komponente. Und gerade diese Komponente ist es, die Code erstens überhaupt erst zu "Schönheitssachen" macht, die zweitens Erfahrungswerte relevant werden läßt, wenn es darum geht, einen guten oder einen besseren Weg zur Lösung zu finden, und die drittens das Auftreten von Fehlern mehr oder weniger wahrscheinlich macht.

Ich möchte etwas weiter ausholen: Ziel eines jeden professionellen Programmierers (also auch von mir und dir) ist es, Programme ohne Fehler zu schreiben. Merkwürdigerweise lassen sich aber sehr viele Fehler, die in real existierender Software auftritt, in relativ wenige Kategorien einsortieren. Mal so allgemein betrachtet: Wir haben "Buffer Overflows", "Code Injections", "Cross Site Scripting" und so weiter.

Gegen alle diese Fehlertypen sind Kräuter gewachsen: Buffer Overflows in C verhindert man, indem man nur sichere Methoden für den Stackzugriff verwendet und Speicherbereiche vor dem Schreiben auf ausreichende Länge prüft - oder nicht über das Ende des Bereichs hinausschreibt. Code Injections und Cross Site Scripting verhindert man u.a. durch das korrekte, kontextabhängige Maskieren von Steuerzeichen.

Aber wie kriegt man es, ganz allgemein gesprochen, hin, dass Programmierer (also auch du und ich) Fehler im Programmcode schnell entdecken und beheben? Einfache Antwort: Ein Fehler muß wie ein Fehler aussehen, nicht wie korrekter Code.

Denn nur wenn Fehler im Code schnell ins Auge springen, genau wie man in lyrischen Texten Abweichungen in
der
Formatierung
sofort
sieht, weil
sie das optische

Bild

stören

Lassen sich einfache Fehler vermeiden. Und die komplizierteren leichter entdecken. Das Menschliche Auge ist eben sehr stark trainiert auf das Erkennen von Mustern.

Und weil das Auge Mustererkennung in Perfektion beherrscht, muß man unter anderem Dafür sorgen, dass die Mustererkennung beim Betrachten von Programmtext sich vorrangig mit der Erkennung von Musterstörungen - die eben möglicherweise Fehler sein könnten - beschäftigt.

Wenn Dinge, die identisches tun, immer gleich aussehen, hilft das der Mustererkennung enorm. Weil dann jegliche Abweichung von der Norm sofort kritisch unter die Lupe genommen wird:

"Aha, das IF startet seinen Block nicht mit einer geschweiften Klammer! Das ist bestimmt ein Fehler!" ...

Und an dieser Stelle geht die Geschichte dann auf zwei verschiedene Weisen weiter:

1. "Tatsächlich, die Klammer fehlt, unten am Bildschirm wird die Klammer nämlich wieder geschlossen."

2. "Ach nee, doch kein Fehler, das IF hat nur eine einzige Anweisung."

Je häufiger die Geschichte mit Ende Nr. 2 endet, desto unaufmerksamer wird der Programmierer beim Betrachten von IFs, bei denen nicht sofort eine Klammer den IF-Anweisungsblock eröffnet.

Sowas provoziert Fehler - wie ich ja bereits in meinem ersten Posting dargelegt habe. Und solche Fehler kann man vermeiden - indem man nicht alles nutzt, was technisch möglich ist.

Geschweifte Klammern kann man genau dann weglassen, wenn nur eine einzige nachfolgende Anweisung zu diesem IF gehört.
Eben! Und darum ging es im obigen Beispiel.

Nein, die Frage war, ob es nur "Schönheitssache" sei, IF-Blöcke mit nur einer einzigen Anweisung mit oder ohne Klammern zu schreiben.

Und zur Frage "Schönheitssache" sagst du "ja" und ich "nein".

Ich für meinen Teil habe gute Gründe, fehlende Klammern als extrem unschön anzusehen.

Aus genau dem gleichen Grund "Schönheit" rücken Programmierer ihren Code ein. Schreiben KONSTANTEN NUR GROSS. Nutzen $_GET, obwohl in PHP 4 auch $HTTP_GET_VARS existiert. Schreiben Klassen, die exakt das Gleiche tun, wie verfügbare Funktionen der darunterliegenden Programmiersprache, indem sie die Methodenparameter 1:1 der Funktion weiterreichen. Und viele andere Dinge mehr.

Also ich werde mir weiterhin - trotz deines wehementen Belehrungszwanges -
die Klammern bei einer einzeiligen If-Anweisung sparen.
So einfach ist das!

Dir ist, außer der Tatsache, dass meine Antwort sich auf "Schönheitssache" bezog, auch noch entgangen, dass ich nicht DICH belehrt habe (wenn du es denn schon so sehen willst), sondern den Fragesteller han.

Hätte die menschliche Sprache mehr non-optionale Klammern, hätte ich in meinem Antworttext diesen Zusammenhang mit den Bindungen gerne deutlich gemacht. Aber zum Glück darf ich solche Klammern weglassen.

- Sven Rautenberg

[seth]

gudn tach!

Wenn Dinge, die identisches tun, immer gleich aussehen, hilft das der Mustererkennung enorm. Weil dann jegliche Abweichung von der Norm sofort kritisch unter die Lupe genommen wird:

"Aha, das IF startet seinen Block nicht mit einer geschweiften Klammer! Das ist bestimmt ein Fehler!" ...

Und an dieser Stelle geht die Geschichte dann auf zwei verschiedene Weisen weiter:

1. "Tatsächlich, die Klammer fehlt, unten am Bildschirm wird die Klammer nämlich wieder geschlossen."

2. "Ach nee, doch kein Fehler, das IF hat nur eine einzige Anweisung."

Je häufiger die Geschichte mit Ende Nr. 2 endet, desto unaufmerksamer wird der Programmierer beim Betrachten von IFs, bei denen nicht sofort eine Klammer den IF-Anweisungsblock eröffnet.

ich glaube nicht, dass man es sich so einfach mit der diesbzgl. ueberlegung machen darf; zum einen weil das auge mehr als nur ein zeichen gleichzeitig aufnehmen kann und zum anderen weil afaik das muster-verarbeiten stark parallelisiert im kopf ablaeuft und nicht so einfach in die uns bekannten gaengigen algorithmischen formen gepresst werden kann. insofern glaube ich umso weniger, dass man auf diese weise schliessen darf, wie du es hier getan hast.

es geht ja nicht notwendig um "unten am bildschirm", sondern normalerweise nur 1 bis 2 zeilen unter dem "if". und sobald man das "if" sieht, sieht man im selben augenblick (woertlich) auch schon genuegend von der umgebung, um zu erkennen, ob mehr als eine zeile darunter eingerueckt ist oder nicht. insofern braucht man dann bei C&R-einrueckung (keine separaten zeilen fuer oeffnende braces) gar nicht mehr den blick hinter die runde klammer nach der bedingung zu richten, um eine fehlende klammer zu suchen, und spart dann sogar zeit. und bei java-einrueckung (oeffnende braces in seperate zeilen) waer's immerhin gleich schnell/aufwaendig.
aber auch hier wird die betrachtung viel zu sehr vereinfacht, denn so ein if-konstrukt kann ja beliebig kompliziert aussehen, z.b.

if(fooooooooooooooooooooooo
   && (baaaaaaaaaaaaaaaaaar || baaaaaaaaaaaaaaaaz)
   && quux
   && quuux
  ){
    print 'hello world!'."\n";
}

bzw.

if(fooooooooooooooooooooooo
   && (baaaaaaaaaaaaaaaaaar || baaaaaaaaaaaaaaaaz)
   && quux
   && quuux
  ) print 'hello world!'."\n";

usw.

kurz: ich bleibe bei meiner behauptung, dass es geschmackssache ist, da die unterschiede (ob nun vor-/nachteile sei mal dahingestellt) in der praxis vernachlaessigbar gering sind.
aehnlich wie bei den verschiedenen indent-styles, wo uebrigens auch von verschiedenen seiten oft die zum scheitern verurteilten mustererkennungs-argumentationen angesetzt werden, spielt imho die gewohnheit eine viel wesentlichere rolle als der ganze rest.

prost
seth

[Siechfred]

Hell-O!

Aber man sollte sie nicht weglassen. Denn fügt man eine zweite Anweisung hinzu, die auch innerhalb vom IF ausgeführt werden soll, benötigt man die Klammern wieder.

Da stimme ich dir zu und schiebe gleich die Frage nach, ob sowas wie in Perl:

tu_was() if $bedingung;

auch in PHP möglich ist. Denn oben stehende Schreibweise würde die genannte Fehlerquelle vermeiden helfen.

Siechfred

[dedlfix]

echo $begrüßung;

Da stimme ich dir zu und schiebe gleich die Frage nach, ob sowas wie in Perl:
tu_was() if $bedingung;
auch in PHP möglich ist.

Nein, PHP ist in seiner Grundsyntax eher an C angelehnt und da geht sowas auch nicht.

echo "$verabschiedung $name";

[seth]

gudn tach!

Aber man sollte [die geschweiften Klammern] nicht weglassen. Denn fügt man eine zweite Anweisung hinzu, die auch innerhalb vom IF ausgeführt werden soll, benötigt man die Klammern wieder.

das ist wie so vieles beim schreiben zum groessten teil gewohnheitssache. so wie manche leute schliessende braces vergessen, vergessen einige, beim hinzufuegen von zeilen, die oeffnenden und schliessenden braces hinzuzufuegen. und beide fehler sind je nach code leicht oder schwer zu finden.

Um Fehler zu vermeiden, sollte man GRUNDSÄTZLICH KLAMMERN SETZEN, egal wieviele Anweisungen im IF stehen. Vergessene Klammern fallen einem nämlich nicht sofort ins Auge, wenn man "mal so, mal so" schreibt.

Schreibt man IF hingegen IMMER mit Klammern, fällt einem ein IF ohne Klammern sofort auf.

und eben das ist gewohnheitssache. so wie man sich angewoehnen kann, bei einem "if" (oder "for", "else" etc.) und beliebig vielen darauffolgenen eingerueckten zeilen nach einer zeile mit "}" zu suchen, kann man sich angewoehnen, bei einem "if" (etc.) und mind. 2 darauffolgenen eingerueckten zeilen nach einer zeile mit "}" zu suchen.

allerdings kann man das natuerlich auch noch etwas verkomplizieren, indem man z.b. mehrere echte anweisungen wie
  if(foo){
    bar; baz;
  }
in eine zeile quetscht.
wenn sowas vorkommen darf, muss man wohl doch etwas mehr aufpassen oder eben grundsaetzlich klammern setzen.

es gibt uebrigens auch sprachen, in denen das weglassen von begrenzern bei einfachen anweisungen nicht erlaubt ist, z.b. bei matlab _muss_ man immer ein "endif" setzen, was mich schon mehrere male fast zum kotzen verleitete.
selbst in perl liefert bspw. der code
  if(1) print 1;
eine syntax-error-meldung, mit braces waer's ok.
dagegen waere
  print 1 if 1;
korrekt. an dieser stelle moechte ich einfach mal wieder betonen wie geil ich die moeglichkeiten bei der perl-syntax finde.

kurz: es ist imho geschmackssache, ob man es nun so oder so macht.

prost
seth

[Sven Rautenberg]

Moin!

was ist die Beste Möglichkeit, beim ternären Operator dem 'else' keine Funktion zukommen zu lassen? Weglassen darf man es ja nicht...

Der Ternäre Operator liefert Werte zurück, genauso wie z.B. die Sinus-Funktion.

Und ebenso wie die Sinusfunktion kann der ternäre Operator nicht "nichts" zurückliefern, wenn die in ihm ausgewertete Bedingung als falsch bewertet wird, sondern er muß immer irgendwas zurückliefern.

also ich mach das bisjetzt so_:
(bedingung ? dies : '');

sind die '' eine gute Lösung für nichts?

Wenn du an dieser Stelle Strings hast, die du zusammensetzt, ist der Leerstring evtl. das passende "Nichts".

Bei der Addition wäre es ggf. die Zahl 0, bei der Multiplikation die Zahl 1, bei Objekten könnte es "NULL" sein, etc. Es hängt ganz vom konkreten Fall ab.

- Sven Rautenberg