nicht angemeldet dedlfix
Der Martin
dedlfix
dedlfix
dedlfix
dedlfix
dedlfix
Der Martin
dedlfix
Der Martin
dedlfix
Der Martin
dedlfix
Moin!
Ich habe folgende Frage:
Was bewirkt ein Eintrag wie folgender:
${$array[xyz]}
Derzeit arbeite ich an einem Script, welches auf eine andere PHP Version (5) portiert werden soll und scheinbar hakt es da irgendwo.
Ich habe zwar früher ab und zu etwas mit PHP gemacht (Hobby), dies ist mir aber so nie begegnet.
Vielen Dank für eure Hilfe!
MfG
Wolle
Hi!
Was bewirkt ein Eintrag wie folgender:
${$array[xyz]}
Das ist eine variable Variable, deren Name sich aus dem Inhalt des Array-Elements ergibt.
Derzeit arbeite ich an einem Script, welches auf eine andere PHP Version (5) portiert werden soll und scheinbar hakt es da irgendwo.
Das sollte kein Versionsproblem sein. Wenn du eine genauere Analyse haben möchtest, musst du mal mit ein konkretes Beispiel und Problembeschreibung geben.
Lo!
Das ist eine variable Variable, deren Name sich aus dem Inhalt des Array-Elements ergibt.
Danke! Das das so konstruiert wird war mir nicht bekannt!
Das sollte kein Versionsproblem sein. Wenn du eine genauere Analyse haben möchtest, musst du mal mit ein konkretes Beispiel und Problembeschreibung geben.
Stimmt, das Versionsproblem war, dass diese variable Variable mit PHP5 eine $_POST Variable wird.
Vielen Danke für die Hilfe, sonst hätte ich wohl noch länger gesucht ;)
MfG
Wolle
Hallo,
${$array[xyz]}
ach du Sch...
Das bedeutet, im Array $array[] steht der Name der Variablen, die eigentlich angesprochen werden soll. Im einfachsten Fall sieht ein Konstrukt mit variablen Variablen so aus: $$v
Dabei enthält $v einen String, der wiederum als Variablenname interpretiert werden soll.
Wenn aber die Variable, die den Variablennamen enthält, selbst wieder ein Arrayelement, eine Objekteigeschaft oder ein ähnlich komplexer Ausdruck ist, muss sie in geschweifte Klammern gefasst werden, damit der Ausdruck eindeutig ist.
Der Gebrauch von variablen Variablen ist meistens ein Zeichen für einen schweren Designfehler. Üblicherweise kann man dasselbe mit Arrays oder Objekten sehr viel sauberer lösen.
Derzeit arbeite ich an einem Script, welches auf eine andere PHP Version (5) portiert werden soll und scheinbar hakt es da irgendwo.
PHP5 kennt das Konzept aber unverändert. Wie äußert sich das, dass es "hakt"?
Vermutlich bekommst du eine Notice-Meldung, weil du den Index xyz syntaktisch betrachtet als benannte Konstante da stehen hast, die nicht definiert ist - PHP ist dann so gnädig, ihn stattdessen als String zu interpretieren, mault aber berechtigterweise etwas.
Wenn du also sowieso schon an diesem Script rummachen musst, würde ich dir empfehlen, die variablen Variablen auszumisten.
So long,
Martin
Das bedeutet, im Array $array[] steht der Name der Variablen, die eigentlich angesprochen werden soll. Im einfachsten Fall sieht ein Konstrukt mit variablen Variablen so aus: $$v
Dabei enthält $v einen String, der wiederum als Variablenname interpretiert werden soll.
Wenn aber die Variable, die den Variablennamen enthält, selbst wieder ein Arrayelement, eine Objekteigeschaft oder ein ähnlich komplexer Ausdruck ist, muss sie in geschweifte Klammern gefasst werden, damit der Ausdruck eindeutig ist.
Auch Dir vielen Dank für die Hilfe, ohne euch hätte ich noch länger gesucht. Insgesamt war diese variable Variable wohl sogar noch von einem Formular übergeben worden, daher auch der Versionskonflikt.
Der Gebrauch von variablen Variablen ist meistens ein Zeichen für einen schweren Designfehler. Üblicherweise kann man dasselbe mit Arrays oder Objekten sehr viel sauberer lösen.
Gut, dass es nicht mein Script ist ;-)
Derzeit arbeite ich an einem Script, welches auf eine andere PHP Version (5) portiert werden soll und scheinbar hakt es da irgendwo.
PHP5 kennt das Konzept aber unverändert. Wie äußert sich das, dass es "hakt"?
s.o.
Wenn du also sowieso schon an diesem Script rummachen musst, würde ich dir empfehlen, die variablen Variablen auszumisten.
Mal sehen, ob ich die Zeit finde... ;-)
Viele Grüße,
Wolle
Der Gebrauch von variablen Variablen ist meistens ein Zeichen für einen schweren Designfehler. Üblicherweise kann man dasselbe mit Arrays oder Objekten sehr viel sauberer lösen.
Kann auch ziemlich praktisch sein, z.B. wenn man eine Liste von Key-Value-Pairs in die entsprechend benannten (und befüllten) Variablen umwandeln will, um ein Template zu rendern in dem alle Platzhalter als PHP-Variablen realisiert werden:
foreach( $array as $k => $v ) {
$$k = $v;
}
include( $template );
Hab ich mal einer Template-Engine so gemacht die ich mir aus Spaß an der Freunde mal gebastelt habe.
Hi!
foreach( $array as $k => $v ) {
$$k = $v;
}
[extract()](http://de.php.net/manual/en/function.extract.php) scheint dir nicht bekannt zu sein.
> Kann auch ziemlich praktisch sein, z.B. wenn man eine Liste von Key-Value-Pairs in die entsprechend benannten (und befüllten) Variablen umwandeln will, um ein Template zu rendern in dem alle Platzhalter als PHP-Variablen realisiert werden:
Und dann hast du im Template solche Stellen stehen gehabt?
<?php echo $foo ?>
Das wäre nicht gut, denn dann fehlte in der Regel ein htmlspecialchars(). Es anderswo im Code zu verwenden macht es nicht einfacher, zu erkennen, dass es da ist, besonders wenn du dann noch mit v.V. hantierst.
<?php echo htmlspecialchars($foo) ?>
ständig zu notieren finde ich unpraktisch, weswegen ich mir da eine Funktion schriebe, die nicht nur Schreibarbeit abnimmt.
function h($name) {
echo htmlspecialchars($GLOBALS['templatevalues'][$name]);
}
Da kann man gern noch weitere Funktionalität unterbringen, wenn benötigt. Die Verwendung von $GLOBALS (oder global) ist zwar nicht gerade der Renner, aber bei einer Projektgröße, die mit diesem minimalistischen Template-Ansatz auskommt, durchaus vertretbar. Das Ergebnis wäre dann:
<?php h("foo") ?>
Schon wesentlich kürzer als bei korrekter Verwendung von einzelnen Variablen und ist immer noch praktisch, oder nicht?
Lo!
extract() scheint dir nicht bekannt zu sein.
in der tat, ist mir neu.
wieder was gelernt.
Und dann hast du im Template solche Stellen stehen gehabt?
<?php echo $foo ?>
Nee, einen ; hab ich auch noch... ;)
Das wäre nicht gut, denn dann fehlte in der Regel ein htmlspecialchars(). Es anderswo im Code zu verwenden macht es nicht einfacher, zu erkennen, dass es da ist, besonders wenn du dann noch mit v.V. hantierst.
Hmm, dererlei Validitätsprüfungen übernimmt die Templateklasse.
function h($name) {
echo htmlspecialchars($GLOBALS['templatevalues'][$name]);
}
Den Ansatz finde ich wiederrum ungeschickt, immerhin kann es passieren dass mehrere Templates die gleichen Keys beinhalten, die werden dann im GLOBALS-Array vom letzten Wert überschrieben...
(Ja, ich hab mehrere Templates pro Seite)
Schon wesentlich kürzer als bei korrekter Verwendung von einzelnen Variablen und ist immer noch praktisch, oder nicht?
Der Ansatz, den Zugriff innerhalb des Templates nochmal zu kapseln klingt nicht unvernünftig, ich lass mich aber immer gern von den "Großen" inspirieren, Codeigniter und das Zend Framework machen es auch nicht anders...
(Keine Ahnung wie die Programmlogik aussieht, die Templates werden jedenfalls so definiert)
Greetz, zap
Hi!
Und dann hast du im Template solche Stellen stehen gehabt?
<?php echo $foo ?>
Nee, einen ; hab ich auch noch... ;)
Brauchst du aber nicht. Das letzte ; vor einem ?> ist optional. Wenn man ihn vergisst, wenn der Code erweitert wird, ist das auch nicht schlimm, das bekommt man sofort beim ersten Test als Syntaxfehler präsentiert. Und bei den vielen kleinen Stellen wie oben ist er verzichtbar.
Das wäre nicht gut, denn dann fehlte in der Regel ein htmlspecialchars(). Es anderswo im Code zu verwenden macht es nicht einfacher, zu erkennen, dass es da ist, besonders wenn du dann noch mit v.V. hantierst.
Hmm, dererlei Validitätsprüfungen übernimmt die Templateklasse.
Wieso Prüfung? Unbehandelte Werte erzeugen u.U. syntaktische Fehler im Ergebnis und müssen vermieden werden. Da gibt es nichts zu prüfen, nur kontextgerecht zu handeln.
function h($name) {
echo htmlspecialchars($GLOBALS['templatevalues'][$name]);
}Den Ansatz finde ich wiederrum ungeschickt, immerhin kann es passieren dass mehrere Templates die gleichen Keys beinhalten, die werden dann im GLOBALS-Array vom letzten Wert überschrieben...
Wo ist denn der Unterschied zwischen vielen Variablen innerhalb eines Gültigkeitsbereiches und vielen Elementen eines Array? Überschreiben kann man in beiden Situationen. Unaufmerksam und ungetestet programmieren sollte man weder da noch da.
Wenn du eine Klasse verwendest, brauchst du natürlich auch kein $GLOBALS, denn dann kannst du ja eine Eigenschaft als Wertecontainer nehmen. Und h() wäre dann eine Methode der Klasse.
Der Ansatz, den Zugriff innerhalb des Templates nochmal zu kapseln klingt nicht unvernünftig,
Wieso kapseln? Ich sammle die Werte lediglich an einem Ort: in einem Array. (Man braucht dann auch weniger auf Namenskonflikte zu achten, als bei vielen globalen Variablen.) Da ist nichts gekapselt. Kapseln bedeutet den Zugriff abzuschirmen. Und h() in meinem Beispiel schirmt nicht ab, sie ist nur ein Hilfsmittel zur Praktikabilität und Übersichtlichkeit.
ich lass mich aber immer gern von den "Großen" inspirieren, Codeigniter und das Zend Framework machen es auch nicht anders...
Wenn du was "Großes" zur Verfügung hast, dann in der Regel auch ein Projekt, das dessen Verwendung rechtfertigt. Dann solltest du auch entsprechend der Philosophie des "Großen" verfahren und die Diskussion, wie man es im Kleinen macht, erübrigt sich dann.
Mit der eingebauten View-Klasse des Zend Framework jedenfalls braucht es keine v.V. Da füllt man Eigenschaften eines View-Objekts mit den Werten.
Lo!
Brauchst du aber nicht. Das letzte ; vor einem ?> ist optional. Wenn man ihn vergisst, wenn der Code erweitert wird, ist das auch nicht schlimm, das bekommt man sofort beim ersten Test als Syntaxfehler präsentiert. Und bei den vielen kleinen Stellen wie oben ist er verzichtbar.
Code is poetry :p das gehört dazu, dass man sich auch bestimmte optionale Dinge angewöhnt.
Hi!
Brauchst du aber nicht. Das letzte ; vor einem ?> ist optional. Wenn man ihn vergisst, wenn der Code erweitert wird, ist das auch nicht schlimm, das bekommt man sofort beim ersten Test als Syntaxfehler präsentiert. Und bei den vielen kleinen Stellen wie oben ist er verzichtbar.
Code is poetry :p das gehört dazu, dass man sich auch bestimmte optionale Dinge angewöhnt.
Programmieren ist vor allem eine Nachdenk-Tätigkeit. Ich weiß, das mögen nicht alle und wollen stattdessen lieber feste Regeln (mit denen sie dann an unpassenden Stellen auf die Nase fallen können).
Nicht alles was optional ist, bringt Punkte beim Verwenden. Das letzte ?> eines PHP-Dokuments ist auch optional (wenn danach kein HTML-Zeugs mehr steht). Es wegzulassen bringt den Vorteil, dass sich dahinter kein Whitespace ansammeln kann.
Lo!
Hi!
Brauchst du aber nicht. Das letzte ; vor einem ?> ist optional. Wenn man ihn vergisst, wenn der Code erweitert wird, ist das auch nicht schlimm, das bekommt man sofort beim ersten Test als Syntaxfehler präsentiert. Und bei den vielen kleinen Stellen wie oben ist er verzichtbar.
Code is poetry :p das gehört dazu, dass man sich auch bestimmte optionale Dinge angewöhnt.
Programmieren ist vor allem eine Nachdenk-Tätigkeit. Ich weiß, das mögen nicht alle und wollen stattdessen lieber feste Regeln (mit denen sie dann an unpassenden Stellen auf die Nase fallen können).
Ich denke lieber schon vorher für künftige Änderungen, dann muss ich mich später nicht ägern.
z.B. CSS:
foo {
bar: baz
}
baz > x {
qux: 42
}
Wenn nun "bar: baz" in den "baz > x"-Abschnitt soll, muss ich das ding kopieren und an geeigneter stelle einen Strichpunkt einfügen. Wären in beiden Fällen die Strichpunkte bereits gesetzt, würde ich mir diesen nervenden Schritt bei schnellen nachträglichen korrekturen sparen.
Nicht alles was optional ist, bringt Punkte beim Verwenden.
Das hab' ich auch nicht behauptet.
Das letzte ?> eines PHP-Dokuments ist auch optional (wenn danach kein HTML-Zeugs mehr steht). Es wegzulassen bringt den Vorteil, dass sich dahinter kein Whitespace ansammeln kann.
Das widerspricht aber deiner Argumentation - denn bei einem Folgenden Whitespace würde mann (sollte er Probleme machen) ohnehin eine Fehlermeldung erhalten ;)
Hi!
Programmieren ist vor allem eine Nachdenk-Tätigkeit. Ich weiß, das mögen nicht alle und wollen stattdessen lieber feste Regeln (mit denen sie dann an unpassenden Stellen auf die Nase fallen können).
Ich denke lieber schon vorher für künftige Änderungen, dann muss ich mich später nicht ägern.
Dagegen hab ich auch nichts einzuwenden. Wenn es sich bewährt hat, kann man ruhig auch scheinbar überflüssiges anwenden, beispielsweise Codeeinrückung oder optionale Abschlüsse. Da wo es aber absehbar keine Punkte bringt, muss ich es nicht übers Knie brechen. Sich später über etwas zu ärgern ist auch ein Zeichen von damals nicht genutztem Nachdenkpotential.
Nicht alles was optional ist, bringt Punkte beim Verwenden.
Das hab' ich auch nicht behauptet.
Trotzdem scheint dir das Setzen von optionalen Dingen doch recht wichtig zu sein. Oder wie soll ich dann deuten, dass du für ein nicht weiter spezifiziertes Angewöhnen optionaler Dinge plädiertest?
Das letzte ?> eines PHP-Dokuments ist auch optional (wenn danach kein HTML-Zeugs mehr steht). Es wegzulassen bringt den Vorteil, dass sich dahinter kein Whitespace ansammeln kann.
Das widerspricht aber deiner Argumentation - denn bei einem Folgenden Whitespace würde mann (sollte er Probleme machen) ohnehin eine Fehlermeldung erhalten ;)
Das widerspricht weder meiner Philosophie: anwendungsfallabhängige Betrachtung vor sturer Regelanwendung noch dem konkreten Beispiel. Bei dem einen Fall ging es um das letzte ; vor einem (nicht unbedingt letzten) ?> und beim anderen um das letzte ?> eines Dokuments.
Lo!
Trotzdem scheint dir das Setzen von optionalen Dingen doch recht wichtig zu sein. Oder wie soll ich dann deuten, dass du für ein nicht weiter spezifiziertes Angewöhnen optionaler Dinge plädiertest?
So wichtig ist mir die Sache auch nicht - wie du oben erwähnt hast, ich meinte mit diesen optionalen Dingen eher Sachen syntaktischer Natur. Einrückungen, Umbrüche usw sind auch optional aber imho äußerst wichtig um sich in seinem (oder in fremdem) Code zurechtzufinden.
print_r($foo, false); hier ist z.B. das false redundant - es wäre, auch wenn es optional ist, in den meisten Szenarien kein Vorteil es zu setzen.
Das widerspricht weder meiner Philosophie: anwendungsfallabhängige Betrachtung vor sturer Regelanwendung noch dem konkreten Beispiel. Bei dem einen Fall ging es um das letzte ; vor einem (nicht unbedingt letzten) ?> und beim anderen um das letzte ?> eines Dokuments.
Ich hab' kein Wort verstanden :)
Hi!
Trotzdem scheint dir das Setzen von optionalen Dingen doch recht wichtig zu sein. Oder wie soll ich dann deuten, dass du für ein nicht weiter spezifiziertes Angewöhnen optionaler Dinge plädiertest?
So wichtig ist mir die Sache auch nicht - wie du oben erwähnt hast, ich meinte mit diesen optionalen Dingen eher Sachen syntaktischer Natur. Einrückungen, Umbrüche usw sind auch optional aber imho äußerst wichtig um sich in seinem (oder in fremdem) Code zurechtzufinden.
Einrückungen und Umbrüche sind (außer bei Python und teilweise Javascript) ästhetischer Natur und syntaktisch bedeutungslos, für die Verständlichkeit jedoch von hohem Wert. Optionale Zeichen haben keinen Einfluss auf das Ergebnis der Syntaxanalyse seitens des Parsers, sind also syntaktisch bedeutungslos. Ihr Wert für die Verständlichkeit des Codes ist meistens als gering einzuschätzen. Sie nur der Gewohnheit willen zu notieren, halte ich für keinen guten Grund.
Das widerspricht weder meiner Philosophie: anwendungsfallabhängige Betrachtung vor sturer Regelanwendung noch dem konkreten Beispiel. Bei dem einen Fall ging es um das letzte ; vor einem (nicht unbedingt letzten) ?> und beim anderen um das letzte ?> eines Dokuments.
Ich hab' kein Wort verstanden :)
Die potentiell problematischen Whitespaces können sich zwischen das letzte ?> und das Dateiende schleichen. Deswegen bringt es einen Vorteil, es wegzulassen und kann eben wegen der Whitespaces nachteilig sein, wenn man es notiert. Das ; _vor_ einem ?> ist eine andere Baustelle. Beiden ist nur ihre Optionalität gemeinsam. Ob da ein ; vor dem ?> steht, spielt ebenso keine Rolle wie die Anzahl der Whitespaces dazwischen. Das ist von den Auswirkungen her neutral.
Einige Programmierfehler bleiben gelegentlich unerkannt. Ein vergessenes ; beim Anfügen weiteren Codes erzeugt üblicherweise einen Syntaxfehler, fällt also zeitnah auf und verzögert das Testen nur minimal. Ein unüberlegtes ; zu viel kann sich hingegen länger versteckt halten.
if (bedingung);
{
anweisungen;
}
Dies ist völlig korrekte Syntax. Bei nicht erfüllter Bedingung wird der Anweisungsblock ebenfalls ausgeführt. Das muss man beim Testen erst einmal bemerken. Und nicht immer findet man sofort die Ursache für ein Fehlverhalten. Die Art der Klammersetzung kann sogar noch dem Nichtfinden Vorschub leisten, weil das Semikolon und die {-Klammer einen räumlichen Abstand voneinander haben.
if (bedingung); {
anweisungen;
}
Steht die {-Klammer direkt nach dem ; könnte es eher auffallen, dass solch eine Syntax zumindest ungewöhnlich ist.
Deswegen plädiere ich dafür, aufmerksam und bewusst Zeichen zu setzen und nicht nur aus Gewohnheit welche hinzuschreiben.
Hier noch ein Beispiel, wo ich bewusst ein Komma setze:
$foo = array(
bar,
qux,
baz,
);
So notiere ich Array jedoch nicht immer. Ein Element pro Zeile braucht für mich einen Grund, wie Übersichtlichkeit oder eine benötigte leichte Erweiterbarkeit (Copy&Paste&Change oder Umsortieren). Ist das bei kleineren Array nicht gegeben, steht es eben so im Code:
$foo = array(bar, qux, baz);
Jedenfalls ist das Komma nach baz zwar syntaktisch nicht ganz korrekt, aber PHP stört sich nicht daran und erzeugt auch kein leeres Array-Element. Andere Sprachen, wie C# sind da leider pinglicher. Aber speziell bei C# hilft die sehr gute Syntaxunterstützung vom Visual Studio, ein vergessenes Komma beim Einfügen oder Umsortieren schon beim Code-Bearbeiten zu erkennen.
Lo!
Hallo,
Einrückungen und Umbrüche sind (außer bei Python und teilweise Javascript) ästhetischer Natur und syntaktisch bedeutungslos, für die Verständlichkeit jedoch von hohem Wert.
und das ist ein starkes Argument, dieses Mittel zu nutzen, auch wenn es nicht zwingend notwendig ist.
Optionale Zeichen haben keinen Einfluss auf das Ergebnis der Syntaxanalyse seitens des Parsers, sind also syntaktisch bedeutungslos. Ihr Wert für die Verständlichkeit des Codes ist meistens als gering einzuschätzen. Sie nur der Gewohnheit willen zu notieren, halte ich für keinen guten Grund.
Das sehe ich nicht so. Wenn ich mir angewöhne, eine Anweisung in PHP (Javascript, C) *immer* mit einem Semikolon abzuschließen, mach ich mir das Leben leichter, als wenn ich erst überlege, ob ich es an einer bestimmten Stelle nicht auch weglassen könnte.
Und nächste Woche erweitere ich mein Script, und das einst optionale Semikolon ist plötzlich nicht mehr optional.
Zugegeben, in dem Fall wird man durch einen Parse Error sofort darauf gestoßen - aber warum sollte ich erst den Grundstein für einen zukünftigen Fehler legen, den ich durch konsequentes Nicht-Ausnutzen eines Freiheitsgrades von vornherein vermeiden könnte?
Ein unüberlegtes ; zu viel kann sich hingegen länger versteckt halten.
if (bedingung);
{
anweisungen;
}
Um sowas zu notieren, muss man aber schon in einem fortgeschrittenen Stadium geistiger Abwesenheit sein - dass ein sinnvolles if-Statement immer mindestens einen Anweisungsblock (oder eine einzelne Anweisung) enthält, ist wohl klar.
Deswegen empfehle ich ja auch nicht, aus Gewohnheit am Ende jeder Zeile ein Semikolon zu setzen, sondern am Ende jeder Anweisung.
Dies ist völlig korrekte Syntax.
Ja, der if-Zweig besteht aus einer leeren Anweisung.
Hier noch ein Beispiel, wo ich bewusst ein Komma setze:
$foo = array(
bar,
qux,
baz,
);
Das ist aber sinngemäß dasselbe wie ein optionales Semikolon an einer Stelle, wo es nicht sein muss.
Es ist zwar praktisch, das so zu notieren, weil Smith & We..., äh, Copy & Paste damit problemlos wird. Aber es kann je nach Programmiersprache sinnverändernd sein - im Gegensatz zum unnötigen Semikolon.
Jedenfalls ist das Komma nach baz zwar syntaktisch nicht ganz korrekt, aber PHP stört sich nicht daran und erzeugt auch kein leeres Array-Element.
Klassische Sprachen wie etwa C/C++ schon, C# hast du selbst erwähnt.
Ich bin deswegen durchaus dafür, dass man sich durch konsequente Anwendung von Gewohnheiten das Leben leichter macht.
So long,
Martin
Hi!
Optionale Zeichen haben keinen Einfluss auf das Ergebnis der Syntaxanalyse seitens des Parsers, sind also syntaktisch bedeutungslos. Ihr Wert für die Verständlichkeit des Codes ist meistens als gering einzuschätzen. Sie nur der Gewohnheit willen zu notieren, halte ich für keinen guten Grund.
Das sehe ich nicht so. Wenn ich mir angewöhne, eine Anweisung in PHP (Javascript, C) *immer* mit einem Semikolon abzuschließen, mach ich mir das Leben leichter, als wenn ich erst überlege, ob ich es an einer bestimmten Stelle nicht auch weglassen könnte.
Gerade Javascript wartet da mit recht gemeinen Eigenheiten auf, wenn man sich blind darauf verlässt, dass ein Semikolon eine Anweisung beendet. Denn Javascript ist es egal, ob da aus Versehen oder mit Absicht ein Semikolon fehlt oder vielleicht eine ganz andere Absicht hinter einem Konstrukt steckt.
function foo() {
return
42;
}
Der Rückgabewert der Funktion lautet? "undefined". Hä? Warum nicht 42? Ist doch syntaktisch fehlerfrei und ein Semikolon ist auch da. - Das Semikolon schließt jedoch nicht das "return 42" ab sondern nur die "42". Das "return" ist bereits am Zeilenende implizit abgeschlossen. Semikolon war da, trotzdem auf die Nase gefallen. Das Wissen um die Optionalität ist hier wichtiger als eine Angewohnheit. In diesem Beispiel darf die 42 einfach nicht in der nächsten Zeile stehen, Semikolon hin oder her.
Ein anderes Beispiel ist die Geschichte mit den Zahlen in SQL-Statements. Ein gewohnheitsmäßig angewendetes mysql_real_escape_string() lässt die Tür offen, für die es der Autor vorgesehen hatte.
Oder (Situation: PHP, innerhalb einer Funktion):
return ($variable);
Die Klammern sind hier optional, in anderen Situationen sind sie Pflicht, manchmal helfen sie einfach nur beim Vermitteln der Intention, werden aber wegen der Operatoren-Rangfolge eigentlich gar nicht gebraucht. Also kann es ja wohl nicht schaden, sie immer und auch hier zu notieren. Das geht auch solange gut, bis man mal nicht nur einen Wert sondern eine Referenz zurückgeben will, was durch die Klammern wirksam verhindert wird.
Wegen solcherlei Fallstricken bin ich kein Fan von sturer Regelanwendung. Das Wissen ist wichtig, nicht stur gelernte und nicht hinterfragte Regeln.
Mit genügend Erfahrung weiß man, wann man auf etwas optionales verzichten kann, wann es besser ist, das zu tun, und wann man sich eine Regelübertretung nicht erlauben darf. Diese Erfahrung muss man aber erst einmal sammeln, wozu ein gezieltes Regelverlassen notwendig ist. (Nicht zu verwechseln mit dem Sich-Auf-Eine-Regel-Verlassen.)
Und nächste Woche erweitere ich mein Script, und das einst optionale Semikolon ist plötzlich nicht mehr optional.
Ja, und? Verstand ausgeschaltet beim Erweitern? Wenn nicht sollte es doch kein gravierendes Problem sein, das eine poplige Zeichen hinzuzufügen. Wem solch ein Fehler nicht spätestens beim Testen auffällt, sollte sich fragen, wie er seine Programmierfähigkeiten verbessern kann.
Zugegeben, in dem Fall wird man durch einen Parse Error sofort darauf gestoßen - aber warum sollte ich erst den Grundstein für einen zukünftigen Fehler legen, den ich durch konsequentes Nicht-Ausnutzen eines Freiheitsgrades von vornherein vermeiden könnte?
Weil du, wenn du es richtig machen willst, im Prinzip genausoviel Aufwand in das Überprüfen der Richtigkeit einer Angewohnheitshandlung stecken müsstest wie in das Finden der am besten zur Situation passenden Lösung. Erfahrung hilft, sich schnell für den "richtigen" Weg entscheiden zu können. Erfahrung sollte aber nicht mit Scheuklappen verwechselt werden, finde ich.
Um sowas zu notieren, muss man aber schon in einem fortgeschrittenen Stadium geistiger Abwesenheit sein
Ich hoffe, du beziehst das nicht auch auf die Notation von Beispielen :-)
Deswegen empfehle ich ja auch nicht, aus Gewohnheit am Ende jeder Zeile ein Semikolon zu setzen, sondern am Ende jeder Anweisung.
Klappt nur nicht in jedem Fall für Javascript. Schon versagt deine Gewohnheit.
[...]
Ich bin deswegen durchaus dafür, dass man sich durch konsequente Anwendung von Gewohnheiten das Leben leichter macht.
Das Problem ist nur, dass man leicht was übersehen kann, wenn man sich auf die Gewohnheiten verlässt, jedoch in Situationen kommt, in denen sie halt nicht passen und das nicht mitbekommt. Deswegen bin ich dafür, den Verstand immer eingeschaltet zu lassen - auch bei den gewöhnlichen Dingen. Oder anders gesagt: sich zur Regel zu machen, Regeln immer zu hinterfragen.
Lo!
Hallo,
Wenn ich mir angewöhne, eine Anweisung in PHP (Javascript, C) *immer* mit einem Semikolon abzuschließen, mach ich mir das Leben leichter, als wenn ich erst überlege, ob ich es an einer bestimmten Stelle nicht auch weglassen könnte.
Gerade Javascript wartet da mit recht gemeinen Eigenheiten auf, wenn man sich blind darauf verlässt, dass ein Semikolon eine Anweisung beendet.
ja, ich weiß - Javascript ist ja auch eine Art Bastard unter den Programmiersprachen. Ziemlich unanständig, ziemlich dreckig. PHP ist da nur wenig besser.
function foo() {
return
42;
}
Der Rückgabewert der Funktion lautet? "undefined".
Richtig. Was manche noch viel seltsamer finden: Die Folgezeile 42; ist eine syntaktisch korrekte Anweisung (auch wenn sie hier nie ausgeführt wird).
Das ist eines der Merkmale von Javascript, die ich aufs schärfste kritisiere: Eine Anweisung kann schon mit dem Zeilenumbruch beendet sein, wenn es syntaktisch einigermaßen passt. Das Semikolon ist schmückendes Beiwerk; es kann dastehen, muss aber nicht. Find' ich ganz übel.
In diesem Beispiel darf die 42 einfach nicht in der nächsten Zeile stehen, Semikolon hin oder her.
Stimmt. IMO ein schwerer Designfehler der Sprache an sich.
Oder (Situation: PHP, innerhalb einer Funktion):
return ($variable);
Die Klammern sind hier optional, in anderen Situationen sind sie Pflicht, manchmal helfen sie einfach nur beim Vermitteln der Intention, werden aber wegen der Operatoren-Rangfolge eigentlich gar nicht gebraucht. Also kann es ja wohl nicht schaden, sie immer und auch hier zu notieren. Das geht auch solange gut, bis man mal nicht nur einen Wert sondern eine Referenz zurückgeben will, was durch die Klammern wirksam verhindert wird.
Wenn ich eine Referenz zurückgeben will, mache ich das durch ein vorangestelltes & deutlich. Dann sind auch die Klammern unschädlich. Ja, ich bin stark durch C geprägt. ;-)
Wegen solcherlei Fallstricken bin ich kein Fan von sturer Regelanwendung. Das Wissen ist wichtig, nicht stur gelernte und nicht hinterfragte Regeln.
Da will ich nicht widersprechen. Ich will auch nicht Nachdenken durch Gewohnheit ersetzen, sondern nur unterstützen.
Und nächste Woche erweitere ich mein Script, und das einst optionale Semikolon ist plötzlich nicht mehr optional.
Ja, und? Verstand ausgeschaltet beim Erweitern?
Nein, aber ich muss in einer schon existierenden Code-Zeile wieder etwas ändern und ergänzen. Das müsste nicht sein, wenn ich das Semikolon, das ja hier auch nicht schadet, gleich von Anfang an gesetzt hätte.
Weil du, wenn du es richtig machen willst, im Prinzip genausoviel Aufwand in das Überprüfen der Richtigkeit einer Angewohnheitshandlung stecken müsstest wie in das Finden der am besten zur Situation passenden Lösung.
Richtig. Trotzdem neige ich dazu, solche Freiheitsgrade *nicht* auszunutzen, sondern auch optionale Parameter oder Syntaxelemente hinzuschreiben.
Erfahrung hilft, sich schnell für den "richtigen" Weg entscheiden zu können. Erfahrung sollte aber nicht mit Scheuklappen verwechselt werden, finde ich.
Da sind wir uns einig.
Um sowas zu notieren, muss man aber schon in einem fortgeschrittenen Stadium geistiger Abwesenheit sein
Ich hoffe, du beziehst das nicht auch auf die Notation von Beispielen :-)
Natürlich nicht, Beispiele sollen ja manchmal gerade abschreckend sein.
Deswegen empfehle ich ja auch nicht, aus Gewohnheit am Ende jeder Zeile ein Semikolon zu setzen, sondern am Ende jeder Anweisung.
Klappt nur nicht in jedem Fall für Javascript. Schon versagt deine Gewohnheit.
Nö. Am Ende jeder Anweisung darf ich auch in Javascript ein Semikolon setzen. Ich darf nur nicht an jeder beliebigen Stelle einen Zeilenumbruch machen. Find' ich nicht okay, ist aber so.
Ich bin deswegen durchaus dafür, dass man sich durch konsequente Anwendung von Gewohnheiten das Leben leichter macht.
Das Problem ist nur, dass man leicht was übersehen kann, wenn man sich auf die Gewohnheiten verlässt, jedoch in Situationen kommt, in denen sie halt nicht passen und das nicht mitbekommt.
Ja, deswegen sollte man sich ja bitte die Regel angewöhnen und nicht eine der Ausnahmen.
Oder anders gesagt: sich zur Regel zu machen, Regeln immer zu hinterfragen.
Das tu ich als alter Rebell sowieso immer. Look, that's why there's rules: That you think before you break 'em.
Wenn ich jetzt noch wüsste, wo der Spruch herkommt ...
So long,
Martin
Hi!
Wenn ich eine Referenz zurückgeben will, mache ich das durch ein vorangestelltes & deutlich. Dann sind auch die Klammern unschädlich. Ja, ich bin stark durch C geprägt. ;-)
In PHP kennzeichnet man das im Funktionskopf mit function &foo() {...}, dass man eine Referenz zurückgeben will. Auch beim Zuweisen des Funktionsergebnisses an eine Variablen benötigt man ein zweites Mal den Referenzoperator: $bar =& foo(); Aber schon die Klammern beim return verhindern wirksam, dass eine Referenz nach außen gelangen kann. Wie sieht das denn in C aus? Ich kann mir grad nicht vorstellen, wie der "Referenz-Zurückgeb-Operator" das Klammernpaar außer Gefecht setzen soll. Das würde bedeuten, dass einige Operatoren andere bedeutungslos machen können.
Ich bin deswegen durchaus dafür, dass man sich durch konsequente Anwendung von Gewohnheiten das Leben leichter macht.
Das Problem ist nur, dass man leicht was übersehen kann, wenn man sich auf die Gewohnheiten verlässt, jedoch in Situationen kommt, in denen sie halt nicht passen und das nicht mitbekommt.
Ja, deswegen sollte man sich ja bitte die Regel angewöhnen und nicht eine der Ausnahmen.
Du versuchst dir durch eine Regel das Leben zu erleichtern. Aber zu diesen Regeln musst du auch immer alle Ausnahmen kennen, sonst ist das witzlos. Und dann ist die Frage, ob durch die Regel wirklich etwas vereinfacht wird oder ob sie nur ein falsches Gefühl der Sicherheit erzeugt.
Da sind wir uns einig.
Im Wesentlichen hab ich auch nichts anderes erwartet. Aufgrund unserer Erfahrung wissen du und ich um die Ausnahmen von den Regeln recht gut Bescheid. Doch die noch nicht so Fortgeschrittenen kennen die Ausnahmen noch nicht so gut, weswegen sie die Regelanwendung in solchen Ausnahmesituationen nicht schützt, die Regel also teilweise im Wert mindert.
Lo!
Moin,
Aber schon die Klammern beim return verhindern wirksam, dass eine Referenz nach außen gelangen kann.
tun sie das wirklich? Das würde ja bedeuten, dass gesetzte Klammern den Typ des Operanden verändern, &dummy wäre also etwas anderes als (&dummy) - das fände ich aber sch...
Wie sieht das denn in C aus?
int *min(int a, int b)
{ if (a<b)
return (&a);
else
return (&b);
}
Hier bewusst umständlich formuliert, ohne den ternären Operator zu verwenden.
Ob ich das Argument des return-Statements in Klammern setze oder nicht, ist völlig gleichgültig, es bleibt trotzdem ein int*, also eine Referenz auf ein int.
Ich kann mir grad nicht vorstellen, wie der "Referenz-Zurückgeb-Operator" das Klammernpaar außer Gefecht setzen soll.
Tut er nicht - die Klammern haben keine Funktion, außer der Gruppierung und damit evtl. der Veränderung der Reihenfolge von Operationen. Und so hatte ich das in PHP bisher auch gesehen.
Das würde bedeuten, dass einige Operatoren andere bedeutungslos machen können.
Nein.
So long,
Martin
Hi!
Aber schon die Klammern beim return verhindern wirksam, dass eine Referenz nach außen gelangen kann.
tun sie das wirklich? Das würde ja bedeuten, dass gesetzte Klammern den Typ des Operanden verändern, &dummy wäre also etwas anderes als (&dummy) - das fände ich aber sch...
Siehe Anmerkung auf der verlinkten Handbuchseite. Das Setzen von Klammern bildet einen neuen Ausdruck. (In Konstrukten wie if, for und Funktionen sind sie syntaktischer Bestandteil und nicht Gegenstand der aktuellen Betrachtung.) Es wird also zunächst der geklammerte Ausdruck berechnet und der dann weiterverarbeitet. Der Referenz-Operator steht ja bei PHP nicht (mehr) beim return sondern im Funktionskopf. Um den Klammerausdruck berechnen zu können, wird der Wert von $foo gelesen und verwenden. Zu Berechnen ist zwar nichts weiter, das Ergebnis des Ausdrucks ist nun aber der (nicht weiter berechnete) Wert und nicht eine Referenz. Hier müsste PHP mehr Kontextanalyse treiben, um auszuwerten, a) in welcher Umgebung die Klammerung steht, und b) wie das Funktionsergebnis verwendet wird, um sie als "vermutlich ungewünscht und überflüssig" zu erkennen. Das programmiere mal! Die Alternative wäre vermutlich, Referenzvariablen immer explizit kennzeichnen zu müssen, was PHP nicht vorsieht.
Wie sieht das denn in C aus?
int *min(int a, int b)
{ if (a<b)
return (&a);
else
return (&b);
}Hier bewusst umständlich formuliert, ohne den ternären Operator zu verwenden.
Ob ich das Argument des return-Statements in Klammern setze oder nicht, ist völlig gleichgültig, es bleibt trotzdem ein int*, also eine Referenz auf ein int.
Ich kann mir grad nicht vorstellen, wie der "Referenz-Zurückgeb-Operator" das Klammernpaar außer Gefecht setzen soll.
Tut er nicht - die Klammern haben keine Funktion, außer der Gruppierung und damit evtl. der Veränderung der Reihenfolge von Operationen. Und so hatte ich das in PHP bisher auch gesehen.
Syntaxelemente werden ja aus Sicht des Parsers nicht der Lesbarkeit willen gesetzt, sondern um ihm eine Reihenfolge aufzuzwingen. Das heißt, er muss diese Klammerung in einen Rechenschritt übersetzen. Oder er ist so intelligent, dass er die Klammern hier wegoptimieren kann. Das zu erkennen könnte hier einfacher als bei PHP sein, weil Klammern und Referenz-Operator in unmittelbarer Nähe stehen und die Verwendung der Referenz statt des Wertes nicht wie bei PHP implizit durch anderswo notierte Syntaxelemente erkannt werden muss.
Lo!
Hallo Martin,
Der Gebrauch von variablen Variablen ist meistens ein Zeichen für einen schweren Designfehler. Üblicherweise kann man dasselbe mit Arrays oder Objekten sehr viel sauberer lösen.
Solche Thesen finde ich fragwürdig. Es gibt durchaus Fälle, wo das sehr praktisch sein kann.
Solche Thesen finde ich fragwürdig. Es gibt durchaus Fälle, wo das sehr praktisch sein kann.
Variable Variablen? In einer Sprache in der man mit mehrdimensionalen, assoziativen Arrays arbeiten kann?
Es gibt auch durchaus Anwendungsfälle für ein explizites goto in PHP - aber strukturiert programmiert man heute in PHP doch eher weniger. Prozedurale herangehensweisen haben wesentlich mehr Vorteile und keinen mir bekannten signifikanten Nachteil.
Hi!
Der Gebrauch von variablen Variablen ist meistens ein Zeichen für einen schweren Designfehler. Üblicherweise kann man dasselbe mit Arrays oder Objekten sehr viel sauberer lösen.
Solche Thesen finde ich fragwürdig. Es gibt durchaus Fälle, wo das sehr praktisch sein kann.
Dass es Fälle gibt, in denen variable Variablen sinnvoll sein können, hat er nicht bestritten [*]. Oftmals findet man aber Anwendungen, die besser anders gelöst würden. Willst du mal ein Beispiel bringen, wo es deiner Meinung nach praktisch ist? Wäre doch gelacht, wenn sich das nicht so umschreiben lässt, dass es praktisch bleibt und trotzdem ohne v.V. auskommt.
[*] mich wundert eher, dass er hier Objekte empfiehlt, obwohl er ihnen sonst nicht besonders zugetan ist :-)
Lo!
[*] mich wundert eher, dass er hier Objekte empfiehlt, obwohl er ihnen sonst nicht besonders zugetan ist :-)
Vielleicht spielt er ohne unser Wissen Bullshit-Bingo - aber ich bin mir sicher, er teilt uns das ASAP mit :p
Hi,
[*] mich wundert eher, dass er hier Objekte empfiehlt, obwohl er ihnen sonst nicht besonders zugetan ist :-)
ich meinte eigentlich assoziative Arrays; aber auch Objekte sind meiner Ansicht nach besser als diese unsäglichen variablen Variablen. Ich habe schon versucht, einen Fall zu konstruieren, in dem ich letztere bevorzugen würde - es ist mir nicht gelungen.
Vielleicht spielt er ohne unser Wissen Bullshit-Bingo - aber ich bin mir sicher, er teilt uns das ASAP mit :p
Nö, das Spiel kannte ich noch gar nicht. Liest sich aber recht witzig. :-)
Ciao,
Martin
Hi,
Der Gebrauch von variablen Variablen ist meistens ein Zeichen für einen schweren Designfehler. Üblicherweise kann man dasselbe mit Arrays oder Objekten sehr viel sauberer lösen.
Solche Thesen finde ich fragwürdig. Es gibt durchaus Fälle, wo das sehr praktisch sein kann.
inwiefern widerspricht "es gibt durchaus Fälle" einer These, etwas sei "meistens ein Zeichen" für etwas? Wobei ich zunächst einmal diese Fälle, die es geben mag, für fragwürdig halte, bis das Gegenteil bewiesen ist.
Cheatah
Hi,
Der Gebrauch von variablen Variablen ist meistens ein Zeichen für einen schweren Designfehler. Üblicherweise kann man dasselbe mit Arrays oder Objekten sehr viel sauberer lösen.
Solche Thesen finde ich fragwürdig. Es gibt durchaus Fälle, wo das sehr praktisch sein kann.inwiefern widerspricht "es gibt durchaus Fälle" einer These, etwas sei "meistens ein Zeichen" für etwas? Wobei ich zunächst einmal diese Fälle, die es geben mag, für fragwürdig halte, bis das Gegenteil bewiesen ist.
"These" war bestimmt eine schlechte Wortwahl. Ich finde die Dramatik in der Aussage "ist meistens ein Zeichen für einen schweren Designfehler" unangemessen. Besonders, da kein Konjunktiv benutzt wird. Besser: "Könnte auf einen Designfehler hinweisen, ..."
Bei umfangreicheren Projekten könnte es durchaus mal vorkommen, daß man verschiedene Variablen schnell mit einer foreach-Schleife auf einen bestimmen Wert überprüfen möchte. Das heißt aber, finde ich, noch nicht, daß das Design völlig daneben ist.
Schöne Grüße,
Jonny 5
Hi!
Ich finde die Dramatik in der Aussage "ist meistens ein Zeichen für einen schweren Designfehler" unangemessen. Besonders, da kein Konjunktiv benutzt wird. Besser: "Könnte auf einen Designfehler hinweisen, ..."
Ja, als Empfehlung formuliert gefällt mir das Hinweisen auf günstigere Alternativen deutlich besser.
Bei umfangreicheren Projekten könnte es durchaus mal vorkommen, daß man verschiedene Variablen schnell mit einer foreach-Schleife auf einen bestimmen Wert überprüfen möchte. Das heißt aber, finde ich, noch nicht, daß das Design völlig daneben ist.
Die Frage, die man sich dabei stellen sollte, ist, warum über den Namen iterierbare Variablen besser sein sollen, als gerade auch für Iterationen vorgesehene und optimierte Konstrukte wie Arrays. Da fallen mir spontan keine vernünftigen Argumente ein. V.V. haben durchaus ihre Berechtigung, aber in solchen Anwendungsfällen eher nicht.
Lo!
Hi,
"These" war bestimmt eine schlechte Wortwahl.
ersetze den Begriff durch etwas anderes Sinnvolles.
Ich finde die Dramatik in der Aussage "ist meistens ein Zeichen für einen schweren Designfehler" unangemessen. Besonders, da kein Konjunktiv benutzt wird. Besser: "Könnte auf einen Designfehler hinweisen, ..."
Der Konjunktiv wäre unangemessen, da es sich bei der Behauptung, es sei meistens ein solches Zeichen, eine schlichte Tatsache ist.
Bei umfangreicheren Projekten könnte es durchaus mal vorkommen, daß man verschiedene Variablen schnell mit einer foreach-Schleife auf einen bestimmen Wert überprüfen möchte. Das heißt aber, finde ich, noch nicht, daß das Design völlig daneben ist.
Nein, und die beanstandete Aussage lässt dies auch absolut zu.
Cheatah
Hi,
Was bewirkt ein Eintrag wie folgender:
${$array[xyz]}
Was er bedeutet, lässt sich vielleicht einfacher erklären:
Da hat jemand Arrays benutzt, weil er „musste“, aber nicht, weil er verstanden hat, wie man sie sinnvoll einsetzt und mit ihnen umgeht.
MfG ChrisB
${$array[xyz]}
ist gleichbedeutend mit
$GLOBALS[ $array[xyz] ]
oder auch
$LOCALS = func_get_args()
$LOCALS[ $array[xyz] ]
Hi,
${$array[xyz]}
ist gleichbedeutend mit
$GLOBALS[ $array[xyz] ]
Nein, ist es nicht.
Die Verwendung „variabler Variablen“ hat keinen Einfluss auf den Scope.
MfG ChrisB