PHPで<?=タグを使用するのは悪い習慣ですか?


190

私は<?= ?>最近このPHPタグに出くわし、使用することに消極的です。短いタグを使用するのは悪い習慣で<? ?>あり、<?php ?>代わりに完全なタグを使用する必要があることを知っていますが、これについてはどう<?= ?>ですか?

タイピングを節約し、コードを読みやすくするためにはIMOが適しています。したがって、これの代わりに:

<input name="someVar" value="<?php echo $someVar; ?>">

このように書くことができます。

<input name="someVar" value="<?= $someVar ?>">

この演算子を使用するのは嫌いですか?


11
この種の問題の問題は、それが非常に熱心であることです。「技術的に」正しい方法でも間違った方法でもありません。一部の人は、そのすべての好みを主張し、反対する人もいます。最終的にはあなた次第です。
mseancole

可能であれば、任意の形式の終了タグを避けます。つまり、ファイルにはphpコードのみが含まれます(htmlなどは含まれません)。終了タグがある場合、それ以降の文字はブラウザに出力されます(Webアプリの場合)-問題のデバッグが非常に困難になる可能性があります。詳細:stackoverflow.com/a/4453835/49560
dharm0us

非意見関連:echoXSSに非常に簡単につながるため、注意してください。コンテキスト専用のエコー方式(JSコンテキストの代わりに、またはJSコンテキストに使用するa function html($x) { echo htmlentities($x,...); }とun を持っている)に頼るべきです。これはタグを悪い習慣にします。変数コンテンツを別の場所でHTMLエスケープしたことを意味し、他の場所はこの変数がHTMLコンテキストでエコーされるため、この変数をHTMLエスケープする必要があることを魔法のように知っている必要があるためです html($someVar);echo $someVarecho json_encode($x);<?=
Xenos

回答:


211

歴史

誤った情報の列車が駅から遠ざかる前に、PHPの短いタグについて理解する必要があることがたくさんあります。

PHPの短いタグの主な問題は、PHPが<?別の構文XMLで使用されたタグ()を選択できたことです。

このオプションを有効にすると、構文エラーが発生することなくxml宣言をそのまま出力できませんでした。

<?xml version="1.0" encoding="UTF-8" ?>

これは、XMLの解析と管理がどれほど一般的かを考えると大きな問題です。

どう<?=

<?xmlとの競合は発生しますが、発生し<?= ません。残念ながら、オンとオフを切り替えるオプションはに関連付けられshort_open_tagていたため、短いエコータグ(<?=)のメリットを得るには、短い開始タグ()の問題に対処する必要がありました<?。短いオープンタグに関連する問題は、短いエコータグからの利益よりもはるかに大きかったので、あなたがオンに万人と半分の勧告を見つけることができますshort_open_tagされますが、オフにすべきです

ただし、PHP 5.4では、短いエコータグがshort_open_tagオプションとは別に有効になりました。これは、の利便性を直接支持<?=するものと考えています。それ自体、それ自体に根本的な問題はないからです。

問題は<?=、より広い範囲のPHPバージョンで動作する可能性のあるコードを記述しようとしている場合、あなたが持っていることを保証できないことです。

さて、これですべてが終わりました。

使用すべきです<?=か?

短いエコータグを使用するかどうかに関するフローチャート


71
私はあなたのきびきびした図に同意しません。ほとんどの実稼働環境は短いタグを使用するように構成されているため、正解は99.99%YESです。仮にあなたはそれを吹いたし、彼らは削除<?=あなたは関係なく、ファイルの数千人が、それを使用するどのように多くの、あなただけのプロジェクト全体の検索を行いません&の置き換え、分未満でそれを修正することができ、将来的に<?=ため<?php echo 。私の答えは心配しないでそれを使うだけです。利益は結果を大きく上回ります。<?=もはや短いタグとは見なされていません。ラスマス・ラードルフ自身がそれを非常にコミットしました。
dukeofgaming

32
@dukeofgaming、短いタグを使用するように設定されている本番環境に関するデータをどこで入手していますか?それらを無効にすることは、私が聞いた中で最も一般的に推奨される構成の1つであり、魔法の引用を無効にすることに次ぐものです。また、本番環境とは異なる開発環境を用意することはまったく意味がありません。
zzzzBov

4
5.3 php.net/manual/en/ini.core.php#ini.short-open-tagまでデフォルトで短いタグが有効になっており、私が知っているほとんどのホスティングサービスは問題なくサポートしており、これがKohanaフレームワークの理由の1つでしたそれを奨励するために使用されます。<?=常にオン(stackoverflow.com/a/6064813/156257)であり、ほとんどの場合オンでした。あなたは、あなたの場合は、ホストと確認することで、私が間違っていることを証明することができます彼らが無効になっているとPHP <5.3を使用して、彼らは設定がユーザーまたは特別な要求に応じて上書きすることを許可しない場合は、前のすべてが偽である場合、必ず心配し<?=ます。
dukeofgaming

6
あなたはそれ<?=が削除されることを心配していませんし、私もそうではありません<?=。一部の人々は、特定の言語機能を使用することを不合理に恐れています(PHPで終了タグを残すなど)。
zzzzBov

8
それがまさに私のポイントです。心配する必要はありません。「心配ですか?」と言っただけです。--yes->「先に進んで使用してください。心配する必要はありません」。また、終了タグを省略することは悪い習慣であることを暗示しているように感じますが、そうではありません。
-dukeofgaming

29

PHPの帽子を振り払う

私は間違いなく<?= $someVar ?>、より冗長なecho(単純に個人的な好みよりも)の使用を好むでしょう。唯一の欠点私の知る限りではケースがする前5.4.0を実行しているユーザ用ですshort_open_tagで有効にする必要がありphp.iniを

さて、プロジェクトがOSでない場合、それは論点です。もしそうなら、short_open_tagsを有効にする必要があるという事実を文書化するか、2つのソリューションのうちより移植性の高いものを使用します。


1
Nitpick:PHP 5.4では<?=影響を受けませんがshort_open_tag<?それでも変わりません。短い形式のタグを使用する習慣があれば、どのバージョンで何がサポートされているかを忘れがちです。
ヤニス

7
@YannisRizos <?=テンプレートスタイルで使用する場合は「今変数を出力しています」と<?php、「今は大量のコードを実行しています」と区別するのは良いことです。使用しないことをお勧めします<?が、その両方で問題<?=ありません<?php
イズカタ

2
+1は、Rasmus Lerdorfが短縮形の<?=タグを支持しているためです。PHP 5.4(まもなくリリース予定)での彼の講演を見ました。そのため、PHP 5.4.0以降では<?=タグが常に使用可能です。PHP 5.4より前のコードでは、MVCアプリケーションのビューでは<?=タグが使用されますが、ビュー以外のファイルでは<?php ...?>が使用されます。
プログラマー

@ジェイソンそれは私が言っていることではありません。「ラスマスはfooを支持します」は議論ではありませんが、「ラスマスはこれとその理由でfooを支持します」です。
ヤニス

2
@Yannis Rizos 「ラスマスはこの理由でfooを支持している」とはいえ。指導に感謝しますが、私の理由は、ラスマス・ラードルフが言語の作成者であり、PHPの開発に影響を与え続けていることを支持していたためです。これは、元のコメントに追加すべきでした。「したがって、ビューで<?=を使用する慣行は、おそらくさらに普及するでしょう。」ダン、私はドット... ...今では私のコメントをチェック3倍にする必要があります
プログラマ

21

あなたは間違いなく、それはだかどうか、短い形式のタグを避けるべきです<?<?=

主な技術的理由は移植性です。短い形式のタグが指定されたすべての設定で機能することを確認することはできませんshort_open_tag。しかし、長い形式がどこでも機能することを常に完全に確信することができます。

タイピングを節約し、コードを読みやすくするためにはIMOが適しています。

それも悪い習慣です。あなたがもっと読みやすいと思うものを本当に伝えることはできませんが、コードの読みやすさを言い訳として使用して、いくつかのキーストロークを節約することに熱心に反対しています。読みやすさを懸念する場合は、テンプレートエンジンを使用する必要があります。

<input name="someVar" value="{someVar}">

あなたの両方の例からはるかに読みやすいです。

最後に、PEARZend Frameworkなどの主要なPHPプロジェクトでは、短い形式のタグが明示的に推奨されていないことに注意してください。


14
テンプレートの+1。移植性のために-1。そのサーバー側の言語。サーバーについて集中する必要がある課題は、スケーラビリティやセキュリティなどです。それが複数のプラットフォームで実行されることを確認するために真剣な時間を投資することは驚くほど悪い考えでしょう...(念のため!)
...-riwalk

3
@ Stargazer712 Hm?あなたがする必要があるのは標準<?phpを使用することだけecho<?あり<?=、の代わりに、あなたはそれを深刻な時間として数えますか?そして、何らかの理由で短いタグが無効になっているサーバーにプロジェクトを移動するとどうなりますか?
ヤニス

13
@Yannis:これらの少数のキャラクターはそれほど多くはないように思えるかもしれませんが、IMOは多くのノイズを追加します。
ケビンクライン

8
PHPの本来の目的はテンプレート言語になることでした。PHPの上に別のテンプレートエンジンを追加しても(膨張)、マグロ船が浮きません。HTMLと混合したPHPをコーディングするときは、良い慣行(いくつかの良いヒントはstackoverflow.com/questions/62617/…)に従うだけでよいのです。
プログラマー

2
@Yannis Rizosはい、PHPを初めて使用する人は、純粋なPHPを代わりに使用することを考慮せずに、PHPプロジェクトで[whizbang]テンプレートエンジンを使用する義務があると考える可能性があるため、言及する必要があります。私はPerlのみテキスト処理を行うべきですが、おそらくそうではありませんが、今ではPerlはテキスト処理がかなり上手であることを理解しています-PHPやテンプレートと同様に。
プログラマー

15

PHP-ドキュメントは明確にあなたが安全に短いエコータグを使用することができることを言います:

5.4.0 The tag <?= is always available regardless of the short_open_tag ini setting.

これはPHPバージョン5.4以降用ですが、誰もが少なくともこのバージョンを使用する必要があります。テンプレート化の目的でのみそれらを好むでしょう。


10

短いタグを使用する理由:

  • 短いです。

短いタグを使用しない理由:

  • 彼らはもう1つの構成の落とし穴を導入します-プロフェッショナルなコンテキストでほとんどの場合サーバーを制御しますが、コードを一般に公開する予定がある場合、共有タグなどで使用する人にとって短いタグは修復不能に壊れる可能性があります。
  • これらは、サニタイズされていない文字列を簡単に出力にドロップすることをあまりにも簡単にします。XSSの脆弱性が発生する可能性があるため、これは恐ろしいことです。長いタグはこれを防ぐために直接何もしませんが、彼らがしていることは正しいことではないかもしれないことをプログラマーに知らせます。長いタグを持つ動的な文字列を出力するのは苦痛であり、これは良い(教育的な)ことです。

IMOを受け入れる答えは、thoテンプレートでもXSSがすべて安全になるわけではなく(スクリプトのsrc属性のユーザーデータは常に安全ではない)、テンプレートメカニズムが適切なエコーコンテキストを認識しているかどうかはわかりません。PHP変数がスクリプトタグコンテンツで終わる場合はどうなりますか?HTMLに埋め込まれたSVGで?
Xenos

@Xenosは明らかに問題のテンプレートシステムに依存しており、特効薬はありません。しかし、それらのほとんどはバグの表面を減らし、手動の注意(セキュリティバグの最も重要な単一のソース)が必要なシナリオの数を減らします。「スクリプトタグに動的コンテンツを配置しない」は、「すべての動的コンテンツがどこでも適切にHTMLエンコードされていることを確認する」よりも簡単に追跡(および監査)できます。
タンマー

4

この<?=バージョンは、変数の最終出力にのみ使用し、データの表示に直接関係しない関数呼び出しや三値論理を避けるという条件で、良い/受け入れられるプラクティスだと思います。

確かに<? echo($x); ?>どこよりもずっといいです。

長期的には、Smartyなどのテンプレートエンジンを検討することをお勧めします。


3
Smartyはかつてテンプレートエンジンでしたが現在は時代遅れで肥大化した混乱であり、本当に明確に操作する必要があります。
ヤニス


-3

正直なところ、MVCが既に33年を迎えている間、方法が古いものであれ新しいものであれ、結果をエコーすることはかなり時代遅れなものだと思います。

はい、これは着信サーバー(php)データをXML文書内にカプセル化し、アプリケーション/クライアントレイヤーで処理することをお勧めします。したがって、このようなタグを使用するという考えさえ保存できます。


1
実際にMVCは、それが最初に1979年12月に概説された、33周年を迎え、この論文
ヤニス

ええ、私はまだ2000年です、私の間違い:
sebas

1
ええと...テンプレート化...テンプレート化は時代遅れですか?テンプレートとMVCは相互に排他的ですか?
ティムセギーン
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.