What kind of prefix do you use for member variables?

Question

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

But what kind of prefix do you use?

I have been working on projects where we used m_ as prefix, on other projects we used an underscore only (which I personally don't like, because an underscore only is not demonstrative enough).

On another project we used a long prefix form, that also included the variable type. mul_ for example is the prefix of a member variable of type unsigned long.

Now let me know what kind of prefix you use (and please give a reason for it).

EDIT: Most of you seem to code without special prefixes for member variables! Does this depend on the language? From my experience, C++ code tends to use an underscore or m_ as a prefix for member variables. What about other languages?

Arcboutant

Did we really need two new tags for this question? "member" and "prefix"? I think Coding-style and coding-standard would have been enough. – Cartomancy

Answer 1

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

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

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

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

Third edit: This applies regardless of language.

Urge

That's right, but we sometimes use printouts for code reviews. Without a color printer, you will have no highlighting ... – Arcboutant

So without a color printer for the 1% of your time you spend on code reviews, you have to spend the other 99% with hard-to-read code? Talk to your boss about a printer. – Shipowner

There are other ways to highlight syntax than colour. See the various pretty printers that italicise, embolden, or switch fonts. – Cayuga

I comletely agree with Kevin disputing this claim, and if he did not write this answer I would have done. It really is not essential for understanding code. I can, and have, understood vast amounts of code that did not have prefixed member variables. – Polygenesis

While this holds for languages designed to be parsed in an IDE, such as Java or C#, it does not for C++ nor C (where some struct members each have a prefix unique to that specific struct). This is, IMNSHO, very language-specific, just like most syntax. – Bucktooth

There is one pro fro prefixes: Quick access to member variables via the IDEs outcompletion: type e.g m_ and immediately get all members in a list. While this is not essential it may help forgetful people as me – Darned

This does not "hold" for c# at all. Basically most of you are falling into a logical fallacy: thinking that "because its not a problem for you - its not a problem for anyone". Go with "m_" og "_" for C# - not everyone is you -get over yourselves. Basically a shared syntax is a tool for reviews - its not really targetted at solo developers - its targetted at providing a uniform "language" that other people can understand, independt of your personal quirks and habits. – Adin

I have yet to hear a convincing argument against simple "m" and "s" prefixes. With prefixes, I never have to consider whether I need to use "this" regardless of my current context. It is also obvious, unlike syntax highlighting. The meaning of colors and font styles may vary dramatically between different developer environments. I don't want to learn the meaning of yours if I'm working over your shoulder. Sorry, but this answer's argument is weak. I would never want to work on a project where developers consider the "type and scope of a variable" to be secondary information. – Michale

@JamesWald I agree, and the comment that "for the 1% of your time you spend on code reviews, you have to spend the other 99% with hard to read code" strikes me as silly or maybe whiney. The code review is critically important time where clarity is paramount. All the arguments I'm hearing against the prefix are purely aesthetic preference, and that's an extremely weak premise. I don't buy it. Show me a real reason. – Baritone

A projector for a code review? Handy, on the one hand, but on the other hand, kind of hard for attendees to make notes in the margins of the code like they can if they're looking at a printout. – Baritone

My previous comment was written over 2 years ago and apparently before I had my morning coffee. I have since switched sides and now favor prefix-free fields for new projects. Syntax highlighting differences don't really matter because I'll end up using my own tools anyway. I now appreciate simpler style rules to reduce distracting discourse about style rules. If you want to use simple prefixes there's nothing wrong with that if the team unanimously agrees. There are some benefits such as no this, no shadowing, and more obvious partial-context diffs. – Michale

I'm programming in c++ using visual studio w/ visual assist, for better or worse probably the best ide available for the language. There is no option to color member variables. – Incongruent

Answer 2

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

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

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

Tess

Can those giving me down votes please clarify? The question is "what do you use", not "what is the best and only way". Even if it was "what is the best and only way", certainly everyone can have very different point of view as to what works best for him as an individual, isn't that right? – Tess

I'm with you on this one. If you can't tell your locals from your members, you're putting too much stuff into one place. Better keep one's functions simple. – Vesicant

Religion knows no sense. In any event, your rep is intact using the 5-1 ratio of upvote points to downvote points. – Finger

I'm with you on this one. I must admit that I sometimes write long methods as well, but I do know full well that I SHOULD refactor them to something more sane. (using C#) if there's ever an ambiguity, you can always use the 'this' keyword. – Romans

It's useful when you are passing a variable into a function Function(int value) { m_value = value; } Otherwise you have to think of two different names for 'value' – Cue

@mgb - you could also do: Function(int value) { this.value = value; } – Anissa

I would completely agree with you on this except for one thing: Using a prefix helps emphasize the fact that changing the private variable will persist those changes for other method calls. This emphasis could really help an absent-minded developer avoid creating a new bug. – Selfoperating

+1 for update confirming that your initial take was personally biased and that you now "know better" due to experience. – Adin

@RobSobers you could do this.abcdef = abcdef... and now you have an even subtler issue where you have a variable in a more local scope overriding a variable in the class scope. I would like to see one salient argument about what is functionally right about leaving off the prefix, and what is functionally wrong about including the prefix. Personal taste/aesthetics simply don't count. The bottom line is that the prefix clarifies and improves comprehension, even if somebody doesn't like the way it looks, thus it is a good thing. – Baritone

The fact that you invoke changing tastes and preferences, while stipulating that you've changed to using prefixes for member variables because it has proven beneficial to code comprehension says absolutely everything there is to say about this issue. Who cares about aesthetics? What a red herring aesthetics is. The point is human comprehension of the code, since it's us error-prone humans (for now) writing and maintaining the code. Anything that has a negative impact on comprehension should be discarded as a practice, IMO. – Baritone

Answer 3

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

Turino

The flaw with not using underscore or m_ is when you have name conflicts between member variable names and member function argument names. – Fred

This is not a flaw at all, in my opinion. In c# for example, you can clearly qualify your member variable with this. in case there is a conflict. – Tess

Solve name conflicts by using better names... ;-) – Arboretum

If you keep your methods short enough to be within a single screen (as I have seen recommended) then a glance to the method declaration is all that's needed to clear up where the variable comes from. – Menstrual

It would be nice if IDE's supported coloring member variables differently from other variables. – Stabile

Do you really want to rely on the features of a particular IDE to make your code readable? – Peipeiffer

@RichQ: I'm not relying on a particular IDE. The IDE syntax highlighting is an aid for people with weak memories who can't remember what's a local variable in a one page method - thats why I said "or a decent memory". – Turino

Paul, I was responding to Scott who said "It would be nice if IDE's supported coloring member variables differently from other variables". I'm a staunch m_-er, but I am now doubting having read some comments here.. – Peipeiffer

Eclipse does colour member variables differently and I'm sure you could coerce Vim/Emacs/other non-sucky editors to do the same. – Antabuse

@PaulTomblin And when some other poor schmuck gets assigned to work on "your" code, where you were relying on your "good" memory instead of making the code obvious? ;-) – Baritone

Who cares what people like? The point is code comprehension, and using the underscore (or m_ or s_) improves comprehension. – Baritone

@Craig “Improves comprehension” - improves it how? How are underscores better than using this? – Neonatal

@Neonatal Using this. or this-> is optional, and not everybody will do it. Presuming that you're going to sometimes see the naked variable in code, seeing _foo, m_foo, or s_foo conveys more information than seeing foo. Say what you will, being able to grok the code in a quick eyeball scan without having to hover over the variables to see what the IDE says, or having to scroll to the top (or bottom) of the file to see the declarations then remember them when they're scrolled off the screen is important. – Baritone

@Craig Using this is no more optional than naming your variable with a prefix. I’ve certainly seen both styles ignored. Of course, in each case, you can get Visual Studio to warn you when you’ve not used the correct style. With prefix notation, though, that warning will only be at the point of declaration, whereas if you’re supposed to use this, it will warn you everywhere you don’t. No hovering required. – Neonatal

@Neonatal Visual studio (or more specifically the compiler, regardless of the IDE) will warn you if you try to use an undeclared variable. If you declare int _blah at class scope, you get a compiler error if you try to use blah at a more local scope (unless you declare a new variable). If you see int blah at class scope, you can consider it a breach of the coding standards. Change the declaration, and you have to change all the references (easy). Then, anywhere you see it, you know the scope. Visual Studio can't warn you in a printout or an emailed question from a coworker. – Baritone

Using this.blah or this->blah, on the other hand, is totally optional. You could just use blah without this. My real question is, what is the functional argument against using _, m_', or s_`? I believe the argument is 100% aesthetic, and that just isn't good enough (IMO) when there is a functional argument in favor of the prefixes. – Baritone

@Craig Again, using this is no more optional than using prefixes, if that is your coding standard. I totally agree that aesthetics are not good enough, but the functional argument does not carry enough weight. I can declare int blah at class level and use it at a more local scope, and I won’t see any warning because the warning is at the point of declaration. I will simply think it’s a local variable. If I fail to use this however, I will be warned. – Neonatal

I feel like you’re not really listening. ;-) – Baritone

@Craig :-) Truth is, I could say the same, and this discussion could go on and on. This is not the place for that. But I appreciate your point of view, and for taking the time to discuss it. It’s always good to understand why people like something you don’t, and you raise some interesting points. – Neonatal

Answer 4

Underscore only.

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

Reviere

This is my personal preference, although I do like to use s_ if the field is static. – Baritone

Answer 5

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

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

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

Dunigan

using a trailing underscore fixes the underscore prefix issue in c++. Takes a little getting used to but now I almost prefer it – Obtest

Excellent point regarding diff tools, which is in addition to the issues around using printouts for code reviews. I'm only seeing arguments against using prefixes based on personal aesthetic preference, and with due respect, who cares what the coding guidelines document from Microsoft says? I've seen plenty of examples of Microsoft code with prefixes, and I don't see any functional benefit derived from excluding them. – Baritone

Note that acording to the C++ standard identifiers begining with _ inside a class definition/declaration are Not reserved, so there will be no clash. But many people prefer to use only a trailing _ "just incase" – Catchy

Answer 6

I prefer using this keyword. That means this.data or 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 prefixing variables with letters to denote their type is outdated with good IDEs and reminds me of this Joel's article

Hoodmanblind

This is not a good practice, because it's easy to forget this ;) – Schnabel

@Schnabel It's easy to forget to do a lot of things - that doesn't make it bad practice. – Flit

Answer 7

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

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

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

Prefix notation has value 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 as a form of notation is useful because there are still development environments where smart IDEs are not available. Think about the IDE (a software tool) as allowing us some shortcuts (like intellisense typing), but not comprising the whole development environment.

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

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

Chitchat

Only some databases are case-insensitive, and in fact even Microsoft SQL Server can be configured to be case sensitive with regard to object names. Having said that, I prefer the prefix for purely functional reasons, so I like that you are a proponent, and I find the aesthetics-based reasoning, or reasoning based on the IDE making member variables obvious somehow, to be extremely weak reasoning. – Baritone

Your last paragraph seems to suggest that you think the this. notation is not easily searched and does not allow the variable typing to follow it? Although m_intCustomerID makes me itch. – Neonatal

@Neonatal Write m_iCustomerID instead of m_intCustomerID. Whats important with hungarian notation was to be able to speed read code and understand what it is. Hungarian notation should be adapted to the project that is used for. The reason is that you should try to keep the number of abbreviations as few as possible. All int types could be abbreviated with i today. In the 80s you had NEAR, FAR and HUGE pointers. They needed to adapt to that and other problems related what was hard then. Today for primitive types, you only need i, u, d, it (iterator), b etc, then you have them all – Medawar

Answer 8

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

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

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

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

Hydrolysis

Agree, however FYI: MS Framework Design Guidelines 3.6.4 Naming Fields "The field naming guidelines only apply to static public and protected fields. Internal and private fields are not covered by the guidelines and public or protected fields are not allowed according to ..." – Nameplate

I'm using the Framework Guidelines-book as reference, so it may be a bit behind. Or I remember wrong. Can you link to your statement? From what I remember it says "private fields are not covered... but it is recommended that..." or something like that. – Hydrolysis

How do these two statements collide? the private members are not accessible nor used by other classes in other languages. – Chihuahua

The existence of any public member fields should be viewed as a problem. – Baritone

Microsoft Guidelines is targeted at developers at developers that have problems to code solutions. The whole idea with C# is that developers should avoid coding their own solutions, they should use code from .NET and other libraries. This is most profitable for MS and also good for companies that often need to replace developers. – Medawar

Answer 9

It depends on which framework I'm using! If I'm writing MFC code then I use m_ and Hungarian notation. For other stuff (which tends to be STL/Boost) then I add an underscore suffix to all member variables and I don't 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 may seem a bit odd - two different styles - but it works for me, and writing a lot of MFC code that doesn't use the same style as MFC itself just looks ugly.

Adelaidaadelaide

In MFC it's useful to have m_ for a variable associated with the contents of a control and c_ for the control itself. Otherwise you have to think up two different names for the same item. – Cue

Answer 10

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

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

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

Exorcist

I use m too. But p seems unnecessary. Do you really loose track of parameters? Means your methods are way too long. – Potomac

"if no prefix, then it's a local" - and yet - prepare possibly to have your mind blown - parameters are exactly local variables too, just initialised in a different way, so why prefix those? if you get parameters mixed up with other local variables, you probably need to code more tidily instead. – Sizzle

Answer 11

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

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

All

If you want to use underscores, trailing underscores are the way to go in c++. – Theressa

^ but many people feel member_.submember looks horrible, hence why we settle on the leading underscore and prepend m to avoid clashing with reserved words. upvoted OP for the important note regarding C++. – Sizzle

@Sizzle obviously a matter of taste, but coming from C# I preferred leading underscores so using trailing underscores in C++ was a little unsettling but now it looks completely normal, member_.submember doesn't really bother me at all. – Obtest

Answer 12

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

Oenomel

Answer 13

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

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

Most of the Delphi people just use F.

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

Eogene

Answer 14

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

Leotaleotard

Answer 15

_ instead of this.

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

public class Person {
  private String _name;

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

Compare it with this:

public class Person {
  private String name;

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

I find the first example shorter and more clear.

Lati

The first example is shorter, that’s not a matter of opinion. But I find it less clear. – Neonatal

Answer 16

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.

Nameplate

Answer 17

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

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

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

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

Ngo

Answer 18

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

Dim _valueName As Integer

Public Property ValueName() As Integer

Fuchsin

Answer 19

another trick is naming convention:

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

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

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

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

Semitropical

Answer 20

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

Moonset

Answer 21

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

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

Lapful

Answer 22

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

Semi

Answer 23

It kinda depends what language you're working in.

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

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

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

Openwork

Answer 24

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

Kostroma

Answer 25

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

Maccarone

Answer 26

I use @.

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

Angelitaangell

Answer 27

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

Thunderstone

Answer 28

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

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

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

Auk

Answer 29

I only use a _ suffix (the prefix _ is reserved in c/c++ as many have noted above). I like it mainly because I hate parameter names like 'aCircle', and I don't like writing out this.circle either unless absolutely necessary. (I only do that for public access member variables, 'cos for these I don't use the underscore suffix).

Tallulah

Answer 30

Symbian uses 'i' as a prefix for members and 'a' for parameters.

Enliven

Answer 31

No prefix. And, for purely functional / stack based no variable name. But if I really have to use side effects which I may if I want to output anything then I use p-> where p is an external Pointer to Parameters Passed to my function.

I think using a prefix / prefixes gets silly.

__EXTERN_GLOBAL_hungariannotationvariabletypeVendorName-my_member_prefix-Category-VariableName

Mulling over the mul example, my member variable which is an unsigned long representing the opcode for a multiply instruction might be mulmul.

Robles

Answer 32

If it is really necessary to prefix member variables, I would definitely prefer m_ to just an underscore. I find an underscore on its own reduces readability, and can be confused with C++ reserved words.

However, I do doubt that member variables need any special notation. Even ignoring IDE help, it isn't obvious why there would be confusion between what is a local and what is a member variable.

Tena

Answer 33

None if it's not necessary, single underscore otherwise. Applies for python.

Thrash