ずっと前に、PHPとCSSでプレフィックスとポストフィックスを使用する練習をしました。 これは、何かがローカルの可視性を超えてグローバル空間にある場合に特に当てはまります。Yiiで同じモデルを使用します。
接頭辞と接尾辞が主なタスクを担います-エンティティを可能な限り一意にし、テキストエディタで簡単に見つけられるようにします。 今日、IDEは「Find Usages」という素晴らしいものをサポートしていますが、これは常に役立つとは限りません。これについては、以下で少し説明します。
ハンガリー記法のスタイルで命名するのは好きではありませんでした。 C ++ / Delphi以来、私はこのアプローチが好きではありませんでした-それは冗長であり、常に明確ではないと考えました。 私はBEMの実装が好きでしたが、それも完全には使いません。 私が最も気に入った方法を分離して組み合わせようとしましたが、それらについて説明します。
CSS
すべてのCSSクラスをプレフィックス「cl_」で、識別子をプレフィックス「id_」で開始します。 クラスまたは識別子がブロックに属している場合は、接頭辞「b_」の後に追加します。モジュールの場合は「m_」です。 また、内部状態またはプレフィックス付きのミニブロックを示します。
.cl_b_promoblock {} #id_m_user_list {} #id_m_order_preview .cl_b_user_info {} .cl_user_list_item .cl_visible {} #id_b_main_menu .cl_main_menu_item.cl_selected {}
したがって、私は常に一意で構造的に理解可能な名前を持っています。 また、たとえば、リファクタリングしてそれがどこに反映されるかを確認する必要がある場合、そのような名前を見つけるのははるかに簡単です。
ちなみに、このようなコードは、圧縮と難読化を介して簡単に操作できます 。 さらに、アナライザーは必要ありません-プレフィックスで正規表現を探して圧縮します。 実際、これが識別子とクラスに異なるプレフィックスが使用される理由です。 圧縮と難読化に関する記事はHabrの視聴者にとって興味深いものになると思います。時間の経過に合わせて整理していきます。
PHP（Yii）
コントローラー、バリデーターなどが何らかの形で間違っています 追加のプレフィックスとポストフィックスがありますが、モデルにはありません。 Yiiの「魔法」のため、Userクラスが使用されている場所を見つけることは困難であり、単純なテキスト検索では、Userという単語を可能な限り見つけることができます。
したがって、モデルクラスはWbUserModel、WbCatalogItemModelなどと呼ばれます。ここで、
- Wb：プロジェクト識別子（名前の略）;
- ユーザー：実際にはモデル。
- モデル：それはモデルであり、他のものではないことを意味します。
バリデーター（WbExistsByPkValidator、WbCensureValidator）および独自の補助ライブラリー（LArray、LTime、LString） （プレフィックス「L」はLibraryの略語）もこのパターンに該当します。 ライブラリについては、StringLibまたはArrayLibを使用することもできますが、私の意見では、接頭辞「L」がそれらをファイルリストに次々と追加するので便利です。 ちなみに、「スコープ」メソッドには、「通常の」メソッドと区別するために、ScopePublished（）やScopeLast（int $ limit）などのプレフィックスも追加します。
そのような名前を使用すると一意性が得られます。その場合、IDEがなくても特定のクラスのすべての使用方法を見つけることができます。 また、あらゆる方法でクラスと属性のテキスト表現の使用を放棄しようとしています。特に、文字列の結合からクラスへのリンクが生成される場合、これを大きな悪と考えます。 例：
public function actionGetData($object_type) { $model_class = 'Wb' . $object_type . 'Model'; $model = new $model_class(); return $model; }
Yiiでのリレーションの命名には、特別なプレフィックス「R _」 （Relationの略）も使用します。 したがって、一見すると、これがモデルの属性ではなく、別のモデルとの接続であることはすぐに明らかになります。 Yiiの概念によれば、これはまったく同じもの（モデルの属性）として提示されますが、私はまだこれらは異なるものだと思います。 プレフィックスを追加する以外に、常にモデルクラス名も追加します。 はい、このアプローチはそれほど美しくないかもしれませんが、ドライで具体的です-コードを見ると、それが何に依存していて、データがどこから来たかをすぐに理解します。
public function relations() { return array( 'R_PriceItems' => array(self::HAS_MANY, WbCatalogPriceItemModel::CLASS, 'category_id'), 'R_CategoryParent' => array(self::BELONGS_TO, WbCatalogCategoryModel::CLASS, array('parent_id' => 'id'), ) } public function RecalculatePriceItems() { foreach ($this->R_PriceItems as $price_item) { $price_item->price = $price_item->new_price; } }
上記のコード（relationsメソッド）でわかるように、テキストではなく、関連モデルのクラスを動的に定義します。 ただし、これはPHP> 5.5でのみ可能です。 サーバーがこのバージョンのPHPをサポートしていない場合（そしてその可能性が高い場合）、 ActiveRecordを拡張し、CLASSの代わりに_CLASS_（）メソッドを使用できます。 その後、PHP> 5.5に切り替えた後、_CLASS_（）を簡単な「検索と置換」でCLASSに問題なく置き換えることができます。
class ActiveRecord extends CActiveRecord { public static function _CLASS_() { return get_called_class(); } }
「FOR」または「AGAINST」
私の環境には、「FOR」と「AGAINST」の両方のような名前付けのアプローチの支持者がいます。
特に、プライベートプロパティとメソッドにはプレフィックス「_」 （$ _items、$ _version）を使用します。 データベース内のテーブルでプロジェクトのプレフィックスを示す場合がよくあります（例：wb_catalog_item）。 すべてのYouTubeページのソースコードには、HTMLおよびCSSの接頭辞「yt-」が含まれています（これは、サードパーティのサイトに接続するときに競合がないことを保証する可能性が最も高い） 。
このような命名スキームに対して、この情報は冗長であり、 （実際には）プレフィックスとポストフィックスでコードを散らかす価値がないという事実を引用できます。 さらに、他の（および新しい）従業員に、どのように名前を付けるかを理解するように教える必要があります（個人的にはこれを問題とは考えていませんが）。
はい、プレフィックスとポストフィックスはコードの書き込みを多少遅くしますが、コードは一度だけ書き込まれ、複数のコードが読み取られてリファクタリングされます。 私の場合、コードを読む方がはるかに簡単です。コードを読むと、接頭辞と、モデル属性、メソッド、スコープ、リレーションの場所によってすぐに判断できます。 接頭辞「R_」は、これが接続であることを明確に示し、接尾辞「Model」はそれがモデルであることを明確にします。 たとえば、WebUserクラスがあります-これはコンポーネント（CWebUserを拡張する）であり、Userクラスがあります-これは既にモデルです。
そして最後に... Yiiは至る所でコールチェーンを使用します。 たとえば、$ category-> first_item-> store。 この場合、storeは関係であり、これは倉庫との通信を意味します。 ただし、ある時点で、storeという新しい列をcatalog_itemテーブルに追加する必要があります。 これが問題の始まりです。通常のアプローチでは、コード分析がなければ、ストア接続を他のものに置き換えて置換することはできないため、名前の競合はありません。 プレフィックスを使用する場合、1-2-3分ですべてが「検索と置換」のレベルで決定されます。
Habrの聴衆から、このアプローチについて建設的な議論を聞きたいと思います。 おそらく、一意でない名前の問題には他の解決策があります。