[ACCEPTED]-What kind of prefix do you use for member variables?-prefix

No doubt, it's essential for understanding 23 code to give member variables a prefix so 22 that they can easily be distinguished from 21 "normal" variables.

I dispute this claim. It's 20 not the least bit necessary if you have 19 half-decent syntax highlighting. A good 18 IDE can let you write your code in readable 17 English, and can show you the type and scope 16 of a symbol other ways. Eclipse does a 15 good job by highlighting declarations and 14 uses of a symbol when the insertion point 13 is on one of them.

Edit, thanks slim: A 12 good syntax highlighter like Eclipse will 11 also let you use bold or italic text, or 10 change fonts altogether. For instance, I 9 like italics for static things.

Another edit: Think 8 of it this way; the type and scope of a 7 variable are secondary information. It 6 should be available and easy to find out, but 5 not shouted at you. If you use prefixes 4 like m_ or types like LPCSTR, that becomes noise, when 3 you just want to read the primary information 2 – the intent of the code.

Third edit: This 1 applies regardless of language.

I do not use any prefix at all. If I run 14 into danger of mixing up local variables 13 or method parameters with class members, then either the method or the class is too long and benefits from splitting up.

This 12 (arguably) not only makes the code more 11 readable and somewhat "fluent", but most 10 importantly encourages well structured classes and methods. In the end, it thus boils 9 down to a completely different issue than 8 the prefix or no-prefix dillema.

UPDATE: well, taste 7 and preferences change, don't they.. I now 6 use underscore as the prefix for member 5 variables as it has proven to be beneficial 4 in recognizing local and member variables 3 in the long run. Especially new team members 2 sometimes have hard time when the two are 1 not easily recognizable.

None. I used to use underscore, but was 9 talked out of it on a project where the 8 others didn't like it, and haven't missed 7 it. A decent IDE or a decent memory will 6 tell you what's a member variable and what 5 isn't. One of the developers on our project 4 insists on putting "this." in front of every 3 member variable, and we humour him when 2 we're working on areas of code that are 1 nominally "his".

Underscore only.

In my case, I use it because 6 that's what the coding standards document 5 says at my workplace. However, I cannot 4 see the point of adding m_ or some horrible 3 Hungarian thing at the beginning of the 2 variable. The minimalist 'underscore only' keeps 1 it readable.

It's more important to be consistent than 25 anything, so pick something you and your 24 teammates can agree upon and stick with 23 it. And if the language you're coding in 22 has a convention, you should try to stick 21 to it. Nothing's more confusing than a 20 code base that follows a prefixing rule 19 inconsistently.

For c++, there's another 18 reason to prefer m_ over _ besides the fact 17 that _ sometimes prefixes compiler keywords. The 16 m stands for member variable. This also 15 gives you the ability disambiguate between 14 locals and the other classes of variables, s_ for 13 static and g_ for global (but of course 12 don't use globals).

As for the comments that 11 the IDE will always take care of you, is 10 the IDE really the only way that you're 9 looking at your code? Does your diff tool 8 have the same level of quality for syntax 7 hilighting as your IDE? What about your 6 source control revision history tool? Do 5 you never even cat a source file to the 4 command line? Modern IDE's are fantastic 3 efficiency tools, but code should be easy 2 to read regardless of the context you're 1 reading it in.

I prefer using this keyword. That means this.data or 4 this->data instead of some community-dependent naming.

Because:

• with nowadays IDEs typing this. popups intellinsense
• its obvious to everyone without knowing defined naming

BTW 3 prefixing variables with letters to denote 2 their type is outdated with good IDEs and 1 reminds me of this Joel's article

We use m_ and then a slightly modified Simonyi 38 notation, just like Rob says in a previous 37 response. So, prefixing seems useful and 36 m_ is not too intrusive and easily searched 35 upon.

Why notation at all? And why not just 34 follow (for .NET) the Microsoft notation 33 recommendations which rely upon casing of 32 names?

Latter question first: as pointed 31 out, VB.NET is indifferent to casing. So 30 are databases and (especially) DBAs. When 29 I have to keep straight customerID and CustomerID 28 (in, say, C#), it makes my brain hurt. So 27 casing is a form of notation, but not a 26 very effective one.

Prefix notation has value 25 in several ways:

1. Increases the human comprehension of code without using the IDE. As in code review -- which I still find easiest to do on paper initially.
2. Ever write T-SQL or other RDBMS stored procs? Using prefix notation on database column names is REALLY helpful, especially for those of us who like using text editors for this sort of stuff.

Maybe in short, prefixing 24 as a form of notation is useful because 23 there are still development environments 22 where smart IDEs are not available. Think 21 about the IDE (a software tool) as allowing 20 us some shortcuts (like intellisense typing), but 19 not comprising the whole development environment.

An 18 IDE is an Integrated Development Environment 17 in the same way that a car is a Transportation 16 Network: just one part of a larger system. I 15 don't want to follow a "car" convention 14 like staying on marked roads, when sometimes, its 13 faster just to walk through a vacant lot. Relying 12 on the IDE to track variable typing would 11 be like needing the car's GPS to walk through 10 the vacant lot. Better to have the knowledge 9 (awkward though it may be to have "m_intCustomerID") in 8 a portable form than to run back to the 7 car for every small change of course.

That 6 said, the m_ convention or the "this" convention 5 are both readable. We like m_ because it 4 is easily searched and still allows the 3 variable typing to follow it. Agreed that 2 a plain underscore is used by too many other 1 framework code activities.

Using C#, I've moved from the 'm_'-prefix 13 to just an underscore, since 'm_' is an heritage from C++.

The official Microsoft 12 Guidelines tells you not to use any prefixes, and 11 to use camel-case on private members and pascal-case on public members. The problem is that this collides 10 with another guideline from the same source, which 9 states that you should make all code compatible with all languages used in .NET. For instance, VB.NET doesn't 8 make a difference between casings.

So just 7 an underscore for me. This also makes it 6 easy to access through IntelliSense, and 5 external code only calling public members 4 don't have to see the visually messy underscores.

Update: I 3 don't think the C# "this."-prefix helps out the "Me." in 2 VB, which will still see "Me.age" the same 1 as "Me.Age".

It depends on which framework I'm using! If 9 I'm writing MFC code then I use m_ and Hungarian 8 notation. For other stuff (which tends 7 to be STL/Boost) then I add an underscore 6 suffix to all member variables and I don't 5 bother with Hungarian notation.

MFC Class

class CFoo  
{  
private:  
    int m_nAge;  
    CString m_strAddress;  
public:  
    int GetAge() const { return m_nAge; }  
    void SetAge(int n) { m_nAge = n; }  
    CString GetAddress() const { return m_strAddress;  
    void SetAddress(LPCTSTR lpsz) { m_strAddress = lpsz; }  
};

STL Class

class foo  
{  
private:  
    int age_;  
    std::string address_;  
public:  
    int age() const { return age_; }  
    void age(int a) { age_ = a; }  
    std::string address() const { return address_; }  
    void address(const std::string& str) { address_ = str; }  
};

Now this 4 may seem a bit odd - two different styles 3 - but it works for me, and writing a lot 2 of MFC code that doesn't use the same style 1 as MFC itself just looks ugly.

I prefix member variables with 'm' and parameters 7 (in the function) with 'p'. So code will 6 look like:

class SomeClass {
    private int mCount;
    ...
    private void SomeFunction(string pVarName) {...}
}

I find that this quickly tells 5 you the basic scope of any variable - if 4 no prefix, then it's a local. Also, when 3 reading a function you don't need to think 2 about what's being passed in and what's 1 just a local variable.

It really depends on the language. I'm a 15 C++ guy, and prefixing everything with underscore 14 is a bit tricky. The language reserves stuff 13 that begins with underscore for the implementation 12 in some instances (depending on scope). There's 11 also special treatment for double underscore, or 10 underscore following by a capital letter. So 9 I say just avoid that mess and simply choose 8 some other prefix. 'm' is ok IMO. 'm_' is 7 a bit much, but not terrible either. A matter 6 of taste really.

But watch out for those 5 _leadingUnderscores. You'll be surprised 4 how many compiler and library internals 3 are so named, and there's definitely room 2 for accidents and mixup if you're not extremely 1 careful. Just say no.

Most of the time, I use python. Python requires 12 you to use self.foo in order to access the 11 attribute foo of the instance of the current 10 class. That way, the problem of confusing 9 local variables, parameters and attributes 8 of the instance you work on is solved.
Generally, I 7 like this approach, even though I dislike 6 being forced to do it. Thus, my ideal way 5 to do thos is to not do it and use some 4 form of attribute access on this or self 3 in order to fetch the member variables. That 2 way, I don't have to clutter the names with 1 meta-data.

I'm weirdo and I prefix member variables 3 with initials from the class name (which 2 is camel-cased).

TGpHttpRequest = class(TOmniWorker)
strict private
  hrHttpClient  : THttpCli;
  hrPageContents: string;
  hrPassword    : string;
  hrPostData    : string;

Most of the Delphi people 1 just use F.

TGpHttpRequest = class(TOmniWorker)
strict private
  FHttpClient  : THttpCli;
  FPageContents: string;
  FPassword    : string;
  FPostData    : string;

If the language supports the this or Me keyword, then 1 use no prefix and instead use said keyword.

another trick is naming convention:

All member variables are 7 named as usual, without any prefix (or 'this.' is 6 it is usual to do so in the project)

But 5 they will be easily differentiated from 4 local variable because in my project, those 3 local variables are always named:

• aSomething: represents one object.
• someManyThings: list of objects.
• isAState or hasSomeThing: for boolean state.

Any variable 2 which does not begin by 'a', 'some' or 'is/has' is 1 a member variable.

Since VB.NET is not case-sensitive, I prefix 3 my member variables with an underscore and 2 camel case the rest of the name. I capitalize 1 property names.

Dim _valueName As Integer

Public Property ValueName() As Integer

I'm with the people that don't use prefixes.

IDEs 13 are so good nowadays, it's easy to find 12 the information about a variable at a glance 11 from syntax colouring, mouse-over tooltips 10 and easy navigation to its definition.

This 9 is on top of what you can get from the context 8 of the variable and naming conventions (such 7 as lowerCamelCase for local variables and 6 private fields, UpperCamelCase for properties 5 and methods etc) and things like "hasXXXX" and 4 "isXX" for booleans.

I haven't used prefixes 3 for years, but I did used to be a "this." prefix 2 monster but I've gone off that unless absolutely 1 necessary (thanks, Resharper).

A single _ used only as a visual indicator. (C#)

• helps to group members with intellisense.
• easier to spot the member variables when reading the code.
• harder to hide a member variable with a local definition.

0

_ instead of this.

I use _ too instead of this. because is just shorter (4 characters 5 less) and it's a good indicator of member 4 variables. Besides, using this prefix you 3 can avoid naming conflicts. Example:

public class Person {
  private String _name;

  public Person(String name) {
    _name = name;
  }
}

Compare 2 it with this:

public class Person {
  private String name;

  public Person(String name) {
    this.name = name;
  }
}

I find the first example shorter 1 and more clear.

It kinda depends what language you're working 20 in.

In C# you can reference any member using 19 the 'this' prefix, e.g. 'this.val', which 18 means no prefixes are needed. VB has a similar 17 capability with 'Me'.

In languages where 16 there is a built-in notation for indicating 15 member access I don't see the point in using 14 a prefix. In other languages, I guess it 13 makes sense to use whatever the commonly 12 accepted convention is for that language.

Note 11 that one of the benefits of using a built-in 10 notation is that you can also use it when 9 accessing properties and methods on the 8 class without compromising your naming conventions 7 for those (which is particularly important 6 when accessing non-private members). The 5 main reason for using any kind of indicator 4 is as a flag that you are causing possible 3 side effects in the class, so it's a good 2 idea to have it when using other members, irrespective 1 of whether they are a field/property/method/etc.

I use camel case and underscore like many 9 here. I use the underscore because I work 8 with C# and I've gotten used to avoiding 7 the 'this' keyword in my constructors. I 6 camel case method-scoped variants so the 5 underscore reminds me what scope I'm working 4 with at the time. Otherwise I don't think 3 it matters as long as you're not trying 2 to add unnecessary information that is already 1 evident in code.

I've used to use m_ perfix in C++ but in 2 C# I prefer just using camel case for the 1 field and pascal case for its property.

private int fooBar;
public int FooBar
{
  get { return fooBar; }
  set { fooBar = value; }
}

I like m_ but as long as convention is used 1 in the code base is used I'm cool with it.

Your mul_ example is heading towards Charles 5 Simonyi's Apps Hungarian notation.

I prefer 4 keeping things simple and that's why I like 3 using m_ as the prefix.

Doing this makes 2 it much easier to see where you have to 1 go to see the original declaration.

I tend to use m_ in C++, but wouldn't mind 5 to leave it away in Java or C#. And it depends 4 on the coding standard. For legacy code 3 that has a mixture of underscore and m_ I 2 would refactor the code to one standard 1 (given a reasonable code size)

I use @.

:D j/k -- but if does kind of depend 5 on the language. If it has getters/setters, I'll 4 usually put a _ in front of the private 3 member variable and the getter/setter will 2 have the same name without the _. Otherwise, I 1 usually don't use any.

For my own projects I use _ as a postfix 3 (as Martin York noted above, _ as a prefix 2 is reserver by the C/C++ standard for compiler 1 implementations) and i when working on Symbian projects.

In Java, one common convention is to preface 1 member variables with "my" andUseCamelCaseForTheRestOfTheVariableName.