Semikolon in einem Tag nicht beenden - eine gute Idee?

8

Es ist möglich, das abschließende Semikolon in einem Tag wegzulassen .

Beispiel:

<table>
  <th><td>Name</td><td>Email</td>
  <? foreach ($receivers as $receiver): ?>
  <tr>
    <td><?= $receiver->name ?></td>
    <td><?= $recevier->email ?></td>
  </tr>
  <? endforeach ?>
</table>

Beachten Sie das <? endforeach ?>ohne Semikolon nach endforeach. Die PHP-Dokumentation sagt:

Das schließende Tag eines PHP-Codeblocks impliziert automatisch ein Semikolon. Sie benötigen kein Semikolon, das die letzte Zeile eines PHP-Blocks beendet.

Warum spreche ich dieses Thema an?

Derzeit arbeiten ich und ein Freund von mir in einem proprietären PHP-Projekt mit MVC (Model-View-Controller). Für die Ansicht habe ich einige PHP-Template-Engines wie Smarty, Moustache evaluiert und sogar meine eigene Template-Engine entworfen. Aber wenn ich lese , dass PHP eine Template - Engine ist in sich etwas ging « Klick » in meinem Kopf. Warum nicht einfach im Team vereinbaren, eine begrenzte Teilmenge von PHP als Template-Engine zu verwenden? Und viele Codeüberprüfungen, um die Regeln einzuhalten?

Und diese Untergruppe könnte so aussehen:

  • Verwenden Sie nur kurze Tags <?, <?=und?>
  • Verwenden Sie nur einfache Ausdrücke ohne Nebenwirkungen, insbesondere weisen Sie keine Variablen zu
  • Verwenden Sie nur if, foreachund includefür Aussagen
  • Verwenden Sie nur die alternative Syntax für Kontrollstrukturen
  • Haben Sie jeweils nur eine Anweisung in einem Tag

Dies ist der Kontext , in dem wir das abschließende Semikolon sind weggelassen, und zwar für <? endforeach ?>, <? endif ?>und <? include("list-contents.php") ?>.

Ich habe jedoch oft gelesen, dass das Weglassen von terminierenden Semikolons eine schlechte Praxis ist. Warum? Ist es überhaupt eine schlechte Praxis?

Ich bin froh, dass PHP das Weglassen des abschließenden Semikolons erlaubt, da dies die visuelle Unordnung in den Vorlagendateien minimiert. Sie sollten meistens wie HTML-Dateien mit nur winzigen PHP-Fragmenten hier und da aussehen. Das obige Beispiel ist das, wonach ich strebe.

Was denkst du darüber? Wenn Sie dagegen sind: warum? Wenn Sie es unterstützen: Warum wäre es eine gute Idee? Was soll ich meinem Partner sagen, wenn er mir einen Text gegen das Weglassen des Semikolons überweist?

Bitte stützen Sie Ihre Meinung mit Fakten, Referenzen oder Ihrer eigenen Erfahrung.

nalply
quelle

Antworten:

1

Ich denke, es ist eine gute Idee, PHP oder zumindest eine Teilmenge davon als Vorlagensprache zu verwenden. Für neue Entwickler ist es einfacher, sich in Ihr System zu integrieren, da keine spezielle Bibliothekssyntax zu lernen ist und Sie nicht den Aufwand haben, dass diese Bibliothek Ihre Vorlage analysiert, nur um sie in PHP umzuwandeln.

Außerdem haben Sie einen Kontext verpasst, in dem Sie das abschließende Semikolon auch in Ihren variablen Echoanweisungen entfernen müssten, z <?= $receiver->name ?>. Wenn Sie in Ihren Vorlagen keine Semikolons verwenden möchten, müssen Sie diese wirklich nicht verwenden. Natürlich verwendet Ihr Codebeispiel sie nicht, aber ich wollte nur auf den fehlenden Kontext hinweisen, in dem keine terminierenden Semikolons verwendet werden sollen.

Das wirklich Wichtige ist das Team-Buy-In und die Gewährleistung der Konsistenz Ihrer Vorlagen. Persönlich finde ich es irritierend, kein Semikolon zu haben ... Ich möchte diese Semikolons instinktiv in all Ihre PHP-Anweisungen einfügen. Haben Sie eine Person in Ihrem Team mit der gleichen OCD-Stufe? Wie werden sie darauf reagieren? Wenn Ihr Team kein Buy-In hat und ein oder zwei Personen vehement dagegen sind, lassen Sie sie ihre Entscheidung verteidigen, dann ist dies möglicherweise nicht der beste Weg.

Eine weitere potenzielle Gefahr wäre die Aufnahme neuer Teammitglieder. Sie können sehr wohl nicht erkennen, dass Sie dies überhaupt tun können, gehen Sie zurück in Ihre Vorlagen und fügen Sie gegebenenfalls alle abschließenden Semikolons ein. Offensichtlich ist dies ein Fall, in dem ein Entwickler nicht so viel über PHP weiß, wie er sollte, aber es ist etwas, das Sie bei Ihrer Entscheidung abwägen möchten. Schulung neuer Nachwuchsentwickler, die in Vorlagen keine terminierenden Semikolons verwenden, sondern anderen Code, den wir verwenden.

tl; dr

Holen Sie sich ein Buy-In von Ihrem Team, stellen Sie sicher, dass Ihre Vorlagen konsistent sind, und planen Sie neue Entwickler, wie sich PHP-Code in Vorlagen von "normalem" PHP-Code unterscheidet (alternative Syntax, kein abschließendes Semikolon, zulässige PHP-Strukturen usw.) ).

Charles Sprayberry
quelle
2

Ich bin alle dafür, sie in diesem Fall wegzulassen, und genau das mache ich, insbesondere weil ich in diesem Zusammenhang nur eine einzeilige Anweisung pro oder Block verwende. Es reduziert die visuelle Unordnung und hat in all den Jahren, in denen ich dies getan habe, nie zu einem einzigen Problem geführt.

Jonathan Patt
quelle
0

Verwenden Sie nur kurze Tags

Bitte Gott nein! Sich auf kurze offene Tags zu verlassen, ist eine schreckliche Idee. Es macht Ihren Code nur weniger portabel. Kurze offene Tags sind auf vielen Systemen standardmäßig nicht aktiviert. Und was ist, wenn Sie den Code an jemanden weitergeben möchten, der ihn deaktiviert hat? Außerdem wird IMHO nichts von kurzen offenen Tags gewonnen.

Verwenden Sie nur die alternative Syntax für Kontrollstrukturen

Ich sehe nicht ein, was Sie davon profitieren würden. Außerdem keine konsistente Codebasis.

Haben Sie jeweils nur eine Anweisung in einem Tag

Das könnte die Dinge auch chaotisch machen. Wenn Sie eine "Vorlage" haben, die überall mit Open / Close-Tags überfüllt ist.

Warum nicht einfach im Team vereinbaren, eine begrenzte Teilmenge von PHP als Template-Engine zu verwenden?

Das hängt davon ab, wer zu diesem Team gehört. ZB werden es nur Leute benutzen, die PHP kennen? Oder haben Sie auch Leute in diesem Team, die die Vorlagen ändern müssen, die PHP nicht kennen? Wenn es das erste ist, würde ich mich nur auf die Anforderungen (auch bekannt als Regeln) entspannen, denn wenn Leute auf ein Problem stoßen, können sie es leicht mit all der Leistung lösen, die PHP bietet, und Sie werden sie darauf beschränken, es zu lösen Regeln oder sehr unordentlichen Code bekommen. Wenn Sie jedoch Leute im Team haben, die PHP nicht kennen, könnten Sie damit einfach so durchkommen.

Um Ihre Frage zu beantworten:

Ich habe jedoch oft gelesen, dass das Weglassen von terminierenden Semikolons eine schlechte Praxis ist. Warum? Ist es überhaupt eine schlechte Praxis?

Beim Codieren (egal in welcher Sprache und in welchem ​​Projekt) müssen Sie immer die Anzahl der WTFs pro Minute in Ihrem Code reduzieren. Es ist also eine schlechte Praxis, denn wenn jemand darauf schaut, denkt er vielleicht zuerst: Hey, da ist etwas seltsam! Es ist nur so, dass PHP-Leute verwendet werden, dass es Semikolons gibt, um Anweisungen zu schließen. Dies kann also wiederum von den Personen in Ihrem Team abhängen (aber Sie haben nach persönlicher Erfahrung gefragt). Außerdem ist es sehr, sehr ärgerlich, zwischen den Syntaxen zu wechseln, wenn Leute sowohl am Frontend (den Vorlagen) als auch am Backend arbeiten. Und ist anfällig für Fehler und Ärger im Team.

Und schließlich über die Tatsache, dass Sie mit PHP etwas tun können: Mit PHP können Sie alle möglichen Dinge tun. Nur diese Tatsache bedeutet nicht, dass Sie es verwenden sollten. Es gab einmal einen Meta-Beitrag zu Stack Overflow, in dem es darum ging, dass Stack Overflow nicht das perfekte Beispiel für seine eigenen Regeln (oder ähnliches :) ist, die auch für PHP verwendet werden könnten. Es gibt alle möglichen FUBAR-Inhalte in PHP (ja, ich habe es gesagt), aber das sollte nicht bedeuten, dass Sie sagen sollten: aber aber PHP erlaubt es. Ratet mal, mit PHP können Sie auch Abfragen ohne Eingabebereinigung ausführen. Mit PHP können Sie auch den gesamten Code in einer einzigen Zeile schreiben. Mit PHP können Sie auch Variablennamen wie erstellen $S0mEvAriBLe. All diese Dinge bedeuten nicht, dass es das Beste ist, was zu tun ist.

Meine 2 Cent

PeeHaa
quelle
Lassen Sie mich Ihre Punkte kommentieren: 1) Alternative Syntax, da HTML-Vorlagen ein anderer Bereich sind als «normales PHP». Ich möchte dies mit verschiedenen Konstrukten betonen. 2) Nur eine Anweisung in einem Tag, da Ansichten meistens HTML mit nur wenig PHP-Code sind. 3) Einschränkung der Leistung von PHP aufgrund der Trennung von Bedenken. In den Ansichten wird nichts über die Anwendung entschieden, berechnet oder abgefragt. Es ist die Aufgabe des Controllers zusammen mit dem Modell. Es würde die Trennung durcheinander bringen, wenn jemand die gesamte Leistung von PHP in einer Ansicht nutzt. Vielen Dank für Ihre Antwort. Es ist hilfreich.
Nalply