Doctrine PHPの注釈処理エンジン、およびDoctrineエンティティとZendフォーム、およびその他の可能性に使用されている注釈、および他の言語での使用、Annotations
が残っているようです。
Zendフォームの注釈の例:
/**
* @Annotation\Filter({"name":"StringTrim"})
* @Annotation\Validator({"name":"StringLength", "options":{"min":1, "max":24}})
* @Annotation\Validator({"name":"Regex","options":{"pattern":"/^[a-zA-Z][a-zA-Z0-9_-]{0,24}$/"}})
* @Annotation\Attributes({"type":"text"})
* @Annotation\Options({"label":"Username:"})
* @Annotation\ErrorMessage("Invalid Username")
*/
public $username;
仕様によれば、処理エンジンの助けを借りてAnnotationBuilder
クラスがZendフォームを構築します。これを行う別の方法は、Zend\Formのクラスとメソッドを介して利用できます。
懸念
注釈は基本的にコメントであり、インタープリターやコンパイラーによる検証の対象ではないことに気づきました。これは私の懸念の一部です。構文が変更された場合、エラーメッセージは表示されず、修正が必要なものはすぐには検出されません。
プロパティを誤って入力するとエラーがどこかで発生すると考えられますが、エラーは発生しません。一部のAnnotationディレクティブを変更しようとしても警告は発行されませんが、デフォルトが想定されます。そのため、注釈を入力しても、セマンティックエラーの構文に関するフィードバックは得られません。
質問
静的および動的にチェックできる他の方法(クラス、メソッド、API、配列)が利用可能な場合、注釈を使用することはコードの品質とメンテナンスに有害ですか?
はい、コメントに別の言語で機能を埋め込む、構文チェックが行われず、エラーが発生してもメッセージが表示されずに失敗する、というのは最適ではなく、メンテナンスの頭痛の種です。私はあなたが提起する懸念をもってこの質問に自分で答えると思います。
そしてyes、私はこれを絶対に避け、それが利用可能であれば他のものを使用します。
私は先に進んで、今やアノテーションを広範囲に使用してきましたが、それはとてもクールだと思います。
良い点は、Annotationsを別のメソッドに変換すると多少の作業が必要になりますが、完全に嫌いになっても、他のメソッドとかなり交換可能であることです。しかし、現在のように、クラスを減らすことでコードをクリーンアップし、「邪魔にならない」と感じ、プログラムによるフォームコントロールでもうまく機能します。
あなたがひどく台無しにした場合、someエラー通知があることもわかりました。たとえば、Annotationsはトークナイザーを使用します。トークナイザーは、期待するものと失敗する場所を通知します。構文は正しいがパラメーターが間違っている場合でも、静かに失敗するため、機能しない理由を調査する必要があります。ただし、常にアノテーションと関連しているわけではありません。たとえば、Zend\Form\Element
を介してタグにHTML属性を追加する場合、その属性にはZend Codeで定義されている特定の名前、つまり「class」または「id」が必要ですが、「randomClassName」(暗黙的に追加されません)