tag - Sind PHP-Kurznamen akzeptabel?




short_open_tag php 7 (17)

Beginnend mit PHP 5.4 ist die echo-Verknüpfung ein separates Problem von kurzen Tags, da die echo-Verknüpfung immer aktiviert ist. Es ist jetzt eine Tatsache:

Der Echo-Shortcut selbst ( <?= ) Ist nun sicher zu verwenden.

Hier sind die Informationen gemäß der offiziellen Dokumentation :

Es gibt vier verschiedene Paare von öffnenden und schließenden Tags, die in PHP verwendet werden können. Zwei davon, <?php ?> Und <script language="php"> </script> , sind immer verfügbar. Die anderen beiden sind kurze Tags und ASP-Stil-Tags und können über die Konfigurationsdatei php.ini ein- und ausgeschaltet werden. Während einige Leute Short Tags und ASP-Style-Tags praktisch finden, sind sie weniger portabel und werden im Allgemeinen nicht empfohlen .

Meiner Erfahrung nach haben die meisten Server kurze Tags aktiviert. Eingabe

<?=

ist viel bequemer als Tippen

<?php echo 

Die Bequemlichkeit der Programmierer ist ein wichtiger Faktor, warum werden sie nicht empfohlen?


Das Problem mit dieser ganzen Diskussion liegt in der Verwendung von PHP als Vorlagensprache. Niemand argumentiert, dass Tags in Anwendungsquelldateien verwendet werden sollten.

Die einbettbare Syntax von PHP ermöglicht jedoch die Verwendung als leistungsstarke Vorlagensprache, und Vorlagen sollten so einfach und lesbar wie möglich sein. Viele haben es einfacher gefunden, eine viel langsamere Add-On-Template-Engine wie Smarty zu verwenden, aber für die Puristen unter uns, die schnelles Rendering und eine reine Code-Basis verlangen, ist PHP die einzige Möglichkeit, Templates zu schreiben.

Das einzige gültige Argument gegen die Verwendung von kurzen Tags ist, dass sie nicht auf allen Servern unterstützt werden. Kommentare zu Konflikten mit XML-Dokumenten sind lächerlich, weil Sie PHP und XML sowieso nicht mischen sollten; und wenn Sie sind, sollten Sie PHP verwenden, um Textfolgen auszugeben. Sicherheit sollte nie ein Problem sein, denn wenn Sie vertrauliche Informationen wie Datenbankzugriffsdaten in Vorlagendateien speichern, dann haben Sie größere Probleme!

Nun zum Server-Support muss man sich allerdings seiner Zielplattform bewusst sein. Wenn Shared Hosting ein wahrscheinliches Ziel ist, sollten kurze Tags vermieden werden. Aber für viele professionelle Entwickler (wie mich), erkennt der Client (und tatsächlich, hängt von der Tatsache ab), dass wir die Serveranforderungen diktieren werden. Oft bin ich für die Einrichtung des Servers selbst verantwortlich.

Und wir arbeiten NIEMALS mit einem Hosting-Provider zusammen, der uns keine absolute Kontrolle über die Serverkonfiguration gibt - in einem solchen Fall könnten wir mit viel mehr Ärger rechnen, als nur die Short-Tag-Unterstützung zu verlieren. Es passiert einfach nicht.

Also ja - ich stimme zu, dass die Verwendung von kurzen Tags sorgfältig abgewogen werden sollte. Aber ich bin auch fest davon überzeugt, dass dies IMMER eine Option sein sollte, und dass ein Entwickler, der sich seiner Umgebung bewusst ist, sich frei fühlen sollte, sie zu benutzen.


Es empfiehlt sich, sie zu verwenden, wenn Sie mit einem MVC-Framework oder einem CMS arbeiten, die über separate Ansichtsdateien verfügen.
Es ist schnell, weniger Code, nicht verwirrend für die Designer. Stellen Sie nur sicher, dass Ihre Serverkonfiguration es erlaubt, sie zu verwenden.


Für den Fall, dass noch jemand darauf achtet ... Ab PHP 5.4.0 ist Alpha 1 <?= Immer verfügbar:

http://php.net/releases/NEWS_5_4_0_alpha1.txt

Es sieht also so aus, als wären kurze Tags (a) akzeptabel und (b) hier, um zu bleiben. Für jetzt zumindest ...


IMHO Leute, die kurze Tags benutzen, vergessen oft, dem zu entfliehen, was auch immer sie sind. Es wäre schön, eine Vorlagen-Engine zu haben, die standardmäßig ausblendet. Ich glaube, Rob A hat einen schnellen Hack geschrieben, um kurze Tags in Zend Frameworks Apps zu umgehen. Wenn Sie kurze Tags mögen, weil es PHP leichter lesbar macht. Dann könnte Smarty eine bessere Option sein?

{$myString|escape}

für mich sieht das besser aus als

<?= htmlspecialchars($myString) ?> 

Ich bin zu lieb von <?=$whatever?> Um es loszulassen. Hatte nie ein Problem damit. Ich werde warten bis es mir in den Arsch beißt. In aller Ernsthaftigkeit haben 85% meiner Kunden Zugang zu php.ini in den seltenen Fällen, in denen sie ausgeschaltet sind. Die anderen 15% nutzen Mainstream-Hosting-Anbieter, und praktisch alle von ihnen haben sie aktiviert. Ich liebe sie.


Konvertieren <? (ohne ein Leerzeichen) zu <?php (mit einem Leerzeichen):

find . -name "*.php" -print0 | xargs -0 perl -pi -e 's/<\?(?!php|=|xml|mso| )/<\?php /g'

Konvertieren <? (mit einem abschließenden Leerzeichen) zu <?php (das nachstehende Leerzeichen beibehalten):

find . -name "*.php" -print0 | xargs -0 perl -pi -e 's/<\? /<\?php /g'

Man muss sich fragen, was der Sinn der Verwendung von kurzen Tags ist.

Schneller zu tippen

MDCore sagte:

<?= ist viel bequemer als das Tippen von <?php echo

Ja, so ist es. Sie sparen 7 Zeichen * X Zeiten in Ihren Skripten.

Wenn ein Skript jedoch eine Stunde oder 10 Stunden oder mehr benötigt, um zu entwerfen, zu entwickeln und zu schreiben, wie relevant sind die wenigen Sekunden, in denen diese 7 Zeichen hier und da nicht für die Dauer des Skripts eingegeben werden?

Im Vergleich zu dem Potenzial für einige Core oder alle von Ihnen Skripte nicht funktioniert, wenn kurze Tags nicht eingeschaltet sind, oder sind aber ein Update oder jemand Änderung der Ini-Datei / Server-Konfiguration stoppt sie arbeiten, andere Potenziale.

Der kleine Vorteil, den Sie gewinnen, kommt der Schwere der potenziellen Probleme nicht annähernd gleich, dh Ihre Website funktioniert nicht oder, schlimmer noch, nur ein Teil davon funktioniert nicht und es ist daher ein Kopfzerbrechen zu lösen.

Einfacher zu lesen

Dies hängt von der Vertrautheit ab .
Ich habe immer gesehen und verwendet <?php echo . Während also <?= Nicht schwer zu lesen ist, ist es mir nicht vertraut und daher nicht einfacher zu lesen .

Und mit Front-End- / Back-End-Entwickler-Split (wie bei den meisten Unternehmen) wäre ein Front-End-Entwickler, der an diesen Templates arbeitet, vertrauter zu wissen , dass <?= Gleich "PHP open tag and echo" ist?
Ich würde sagen, die meisten würden sich mit dem logischeren wohlfühlen. Das heißt, ein eindeutiges PHP-Open-Tag und dann was passiert "Echo" - <?php echo .

Risikoabschätzung
Problem = ganze Site oder Core-Skripte funktionieren nicht;

Das Problempotential ist sehr gering. Die Schwere des Ergebnisses ist sehr hoch = hohes Risiko

Fazit

Sie sparen hier ein paar Sekunden und müssen nicht ein paar Zeichen eingeben, sondern riskieren viel dafür und verlieren dadurch wahrscheinlich auch die Lesbarkeit.

Front- oder Backend-Codierer, die mit <?= Vertraut sind, werden <?php echo besser verstehen, da es sich um Standard-PHP-Dinge handelt - Standard <?php open tag und sehr bekanntes "echo".
(Sogar Front-End-Codierer sollten "Echo" kennen oder sie werden einfach nicht an irgendeinem Code arbeiten, der von einem Framework bedient wird).

Während das Umgekehrte nicht so wahrscheinlich ist, ist es nicht wahrscheinlich, dass jemand logisch folgern wird, dass das Gleichheitszeichen auf einem PHP-Short-Tag "Echo" ist.


Seien wir ehrlich. PHP ist hässlich ohne kurze Tags.

Sie können sie in einer .htaccess Datei aktivieren, wenn Sie nicht zur php.ini :

php_flag short_open_tag on

Short-Tags kommen zurück, weil das Zend Framework die " PHP-Sprache als Vorlage " in ihrer Standard-MVC-Konfiguration verwendet . Ich sehe nicht, worum es in der Debatte geht, die meiste Software, die Sie zu Lebzeiten herstellen werden, wird auf einem Server laufen, den Sie oder Ihr Unternehmen kontrollieren. Solange Sie sich konsequent verhalten, sollte es keine Probleme geben.

AKTUALISIEREN

Nach einiger Arbeit mit Magento , die lange Form verwendet. Als Ergebnis bin ich auf die lange Form von:

<?php and <?php echo

Über

<? and <?=

Scheint wie eine kleine Menge Arbeit, um die Interoperabilität zu gewährleisten.


Um Portabilitätsprobleme zu vermeiden, starten Sie PHP-Tags mit <?php und falls Ihre PHP-Datei rein PHP, kein HTML ist, müssen Sie die schließenden Tags nicht verwenden.


Weil die Verwirrung es mit XML-Deklarationen erzeugen kann. Viele Leute agree with dir agree .

Ein zusätzliches Problem ist der Schmerz, den es erzeugt, alles mit kurzen Tags zu codieren, nur um am Ende herauszufinden, dass der letzte Hosting-Server sie ausgeschaltet hat ...


http://uk3.php.net/manual/en/language.basic-syntax.phpmode.php hat viele Tipps, einschließlich:

Während einige Leute Short-Tags und ASP-Style-Tags bequem finden, sind sie weniger portabel und werden im Allgemeinen nicht empfohlen.

und

Beachten Sie, dass Sie bei der Einbettung von PHP in XML oder XHTML die <?php ?> -Tags verwenden müssen, um mit den Standards konform zu bleiben.

und

Die Verwendung von kurzen Tags sollte vermieden werden, wenn Sie Anwendungen oder Bibliotheken entwickeln, die für die Neuverteilung oder die Bereitstellung auf PHP-Servern gedacht sind, die nicht unter Ihrer Kontrolle stehen, da kurze Tags möglicherweise nicht auf dem Zielserver unterstützt werden. Achten Sie bei portablem, weitervertreibbarem Code darauf, keine kurzen Tags zu verwenden.



I thought it worth mentioning that as of PHP 7:

  • Short PHP tags <? … ?> are gone
  • Since PHP 5.4, Short Print tags <?=… ?> are always enabled, regardless of the short_open_tag setting.

Good riddance to the first one, as it interfered with other languages.

There is now no reason not to use the short print tags, apart from personal preference.

Of course, if you're writing code to be compatible with legacy versions of PHP 5, you will need to stick to the old rules, but remember that anything before PHP 5.6 is now unsupported.

See: https://secure.php.net/manual/en/language.basic-syntax.phptags.php


No, and they're being phased out by PHP 6 so if you appreciate code longevity, simply don't use them or the <% ... %> tags.


  • Kurze Tags sind in einigen Webservern (Shared Hosts usw.) nicht standardmäßig aktiviert, sodass die Übertragbarkeit von Code zu einem Problem wird, wenn Sie zu einem dieser Server wechseln müssen.

  • Lesbarkeit kann für einige ein Problem sein. Viele Entwickler finden vielleicht, dass <?php das Auge als offensichtlicherer Marker für den Anfang eines Codeblocks auffängt als <? wenn Sie eine Datei scannen, besonders wenn Sie mit einer Codebasis mit fest verwobenem HTML und PHP festhalten.





php-shorttags