チュートリアル、例、および主にゲーム開発に関連するその他のコードで、変数に使用されるm_
プレフィックス(m_World
、m_Sprites
、...)をよく見ます。
なぜ人々は接頭辞m_
を変数に追加するのですか?
これは、メンバー変数である変数を定義するための典型的なプログラミング手法です。したがって、後でそれらを使用する場合、スコープを知るためにそれらがどこで定義されているかを見る必要はありません。これは、スコープをすでに知っていて、intelliSenseのようなものを使用している場合にも便利です。m_
およびすべてのメンバー変数が表示されます。ハンガリー記法の一部。 ここの例 のスコープに関する部分を参照してください。
クリーンコード:アジャイルソフトウェアのクラフツマンシップのハンドブックこのプレフィックスの使用に対する明示的な推奨事項があります。
また、メンバー変数の前に
m_
を付ける必要もなくなりました。クラスと関数は、それらを必要としないほど小さくする必要があります。
この例(C#コード)もあります。
悪い習慣:
public class Part
{
private String m_dsc; // The textual description
void SetName(string name)
{
m_dsc = name;
}
}
いい練習:
public class Part
{
private String description;
void SetDescription(string description)
{
this.description = description;
}
}
明示的にあいまいな場合(i.e。、description
メンバーおよびdescription
パラメーター)の場合、メンバー変数を参照するために、言語コンストラクトでカウントします:this
。
これはC++の一般的な慣習です。これは、C++ではメンバー関数とメンバー変数に同じ名前を付けることはできず、ゲッター関数は多くの場合「get」プレフィックスなしで名前が付けられるためです。
class Person
{
public:
std::string name() const;
private:
std::string name; // This would lead to a compilation error.
std::string m_name; // OK.
};
main.cpp:9:19: error: duplicate member 'name' std::string name; ^ main.cpp:6:19: note: previous declaration is here std::string name() const; ^ 1 error generated.
「メンバー」の「m_」状態。プレフィックス「_」も一般的です。
異なる規則/文法を使用してこの問題を解決するプログラミング言語では使用しないでください。
m_
プレフィックスはメンバー変数によく使用されます-その主な利点は、パブリックプロパティとそれを支えるプライベートメンバー変数との明確な区別を作成するのに役立つことだと思います:
int m_something
public int Something => this.m_something;
バッキング変数に一貫した命名規則を設定すると役立ちます。また、m_
プレフィックスはその方法の1つであり、大文字と小文字を区別しない言語で機能します。
これがどれほど役立つかは、使用している言語とツールによって異なります。強力なリファクタリングツールとインテリセンスを備えた最新のIDEは、このような規則の必要性が少なく、これを行う唯一の方法ではないことは確かですが、どのような場合でも慣習に注意する価値があります。
他の回答で述べたように、m_
プレフィックスは、変数がクラスメンバーであることを示すために使用されます。これは、変数の型ではなくそのコンテキストを示すため、ハンガリーの表記とは異なります。
私はm_
をC++で使用していますが、「this」または「self」が必須である他の言語では使用していません。コードを乱雑にするため、C++で 'this->'が使用されるのを見るのは好きではありません。
別の答えは、m_dsc
は「悪い習慣」であり、「説明」であると言います。は「良い習慣」ですが、問題は略語があるため、これはニシンです。
別の回答では、this
と入力するとIntelliSenseがポップアップしますが、優れたIDEには現在のクラスメンバーのIntelliSenseをポップアップするホットキーがあります。
現在の回答を完了するため、また質問は言語固有ではないため、一部のCプロジェクトでは、プレフィックスm_
を使用して、ファイルに固有のグローバル変数を定義し、スコープを持つグローバル変数に対してg_
定義されているファイルよりも大きい。
この場合、プレフィックスm_
で定義されたグローバル変数は、static
として定義する必要があります。
この規則を使用したプロジェクトの例については、 EDK2(UEFIオープンソース実装)コーディング規則 を参照してください。
他の多くの応答で述べられているように、m_はメンバー変数を示すプレフィックスです。 C++の世界で一般的に使用され、Javaを含む他の言語にも伝播されました。
現代のIDEでは、構文の強調表示により、どの変数がlocalであり、どの変数がmembersであるかが明確になるため、完全に冗長です。ただし、90年代後半に構文の強調表示が登場する頃には、この規則は長年にわたって存在し、しっかりと設定されていました(少なくともC++の世界では)。
どのチュートリアルを参照しているのかわかりませんが、次の2つの要因のいずれかが原因で慣習を使用していると思います。
まだ見たことのない引数の1つは、m_
などのプレフィックスを使用して、#define
'dマクロとの名前の衝突を防ぐことができるということです。
Curses/ncursesから#define [a-z][A-Za-z0-9_]*[^(]
で/usr/include/term.h
を正規表現で検索します。