Why use prefixes on member variables in C classes

Question

A lot of C   code uses syntactical conventions for marking up member variables  Common examples include   m memberName for public members  where public members are used at all   memberName for private members or all members   Others try to enforce using this- member whenever a member variable is used   In my experience  most larger code bases fail at applying such rules consistently   In other languages  these conventions are far less widespread  I see it only occasionally in Java or C  code  I think I have never seen it in Ruby or Python code  Thus  there seems to be a trend with more modern languages to not use special markup for member variables   Is this convention still useful today in C   or is it just an anachronism  Especially as it is used so inconsistently across libraries  Haven t the other languages shown that one can do without member prefixes

User · Answer

I like variable names to give only a meaning to the values they contain, and leave how they are declared/implemented out of the name. I want to know what the value means, period. Maybe I've done more than an average amount of refactoring, but I find that embedding how something is implemented in the name makes refactoring more tedious than it needs to be. Prefixes indicating where or how object members are declared are implementation specific.

color = Red;

Most of the time, I don't care if Red is an enum, a struct, or whatever, and if the function is so large that I can't remember if color was declared locally or is a member, it's probably time to break the function into smaller logical units.

If your cyclomatic complexity is so great that you can't keep track of what is going on in the code without implementation-specific clues embedded in the names of things, most likely you need to reduce the complexity of your function/method.

Mostly, I only use 'this' in constructors and initializers.

User · Answer

It is useful to differentiate between member variables and local variables due to memory management  Broadly speaking  heap-allocated member variables should be destroyed in the destructor  while heap-allocated local variables should be destroyed within that scope  Applying a naming convention to member variables facilitates correct memory management

User · Answer

You should never need such a prefix  If such a prefix offers you any advantage  your coding style in general needs fixing  and it s not the prefix that s keeping your code from being clear  Typical bad variable names include  other  or  2   You do not fix that with requiring it to be mOther  you fix it by getting the developer to think about what that variable is doing there in the context of that function  Perhaps he meant remoteSide  or newValue  or secondTestListener or something in that scope   It s an effective anachronism that s still propagated too far  Stop prefixing your variables and give them proper names whose clarity reflects how long they re used  Up to 5 lines you could call it  i  without confusion  beyond 50 lines you need a pretty long name

User · Answer

Other languages will use coding conventions  they just tend to be different  C  for example has probably two different styles that people tend to use  either one of the C   methods   variable  mVariable or other prefix such as Hungarian notation   or what I refer to as the StyleCop method   private int privateMember  public int PublicMember   public int Function int parameter         StyleCop enforces using this  for class members    this privateMember   parameter      In the end  it becomes what people know  and what looks best  I personally think code is more readable without Hungarian notation  but it can become easier to find a variable with intellisense for example if the Hungarian notation is attached   In my example above  you don t need an m prefix for member variables because prefixing your usage with this  indicates the same thing in a compiler-enforced method   This doesn t necessarily mean the other methods are bad  people stick to what works

User · Answer

When reading through a member function  knowing who  owns  each variable is absolutely essential to understanding the meaning of the variable  In a function like this   void Foo  bar  int apples         int bananas   apples   grapes      melons   grapes   bananas      spuds    melons         it s easy enough to see where apples and bananas are coming from  but what about grapes  melons  and spuds  Should we look in the global namespace  In the class declaration  Is the variable a member of this object or a member of this object s class  Without knowing the answer to these questions  you can t understand the code  And in a longer function  even the declarations of local variables like apples and bananas can get lost in the shuffle   Prepending a consistent label for globals  member variables  and static member variables  perhaps g   m   and s  respectively  instantly clarifies the situation   void Foo  bar  int apples         int bananas   apples   g grapes      m melons   g grapes   bananas      s spuds    m melons      These may take some getting used to at first   but then  what in programming doesn t  There was a day when even   and   looked weird to you  And once you get used to them  they help you understand the code much more quickly    Using  this-   in place of m  makes sense  but is even more long-winded and visually disruptive  I don t see it as a good alternative for marking up all uses of member variables    A possible objection to the above argument would be to extend the argument to types  It might also be true that knowing the type of a variable  is absolutely essential to understanding the meaning of the variable   If that is so  why not add a prefix to each variable name that identifies its type  With that logic  you end up with Hungarian notation  But many people find Hungarian notation laborious  ugly  and unhelpful   void Foo  bar  int iApples         int iBananas   iApples   g fGrapes      m fMelons   g fGrapes   iBananas      s dSpuds    m fMelons      Hungarian does tell us something new about the code  We now understand that there are several implicit casts in the Foo  bar   function  The problem with the code now is that the value of the information added by Hungarian prefixes is small relative to the visual cost  The C   type system includes many features to help types either work well together or to raise a compiler warning or error  The compiler helps us deal with types   we don t need notation to do so  We can infer easily enough that the variables in Foo  bar   are probably numeric  and if that s all we know  that s good enough for gaining a general understanding of the function  Therefore the value of knowing the precise type of each variable is relatively low  Yet the ugliness of a variable like  s dSpuds   or even just  dSpuds   is great  So  a cost-benefit analysis rejects Hungarian notation  whereas the benefit of g   s   and m  overwhelms the cost in the eyes of many programmers

User · Answer

I can t say how widespred it is  but speaking personally  I always  and have always  prefixed my member variables with  m   E g    class Person               private         std  string mName       It s the only form of prefixing I do use  I m very anti Hungarian notation  but it has stood me in good stead over the years  As an aside  I generally detest the use of underscores in names  or anywhere else for that matter   but do make an exception for preprocessor macro names  as they are usually all uppercase

User · Answer

The original idea for prefixes on C   member variables was to store additional type information that the compiler didn t know about   So for example  you could have a string that s a fixed length of chars  and another that s variable and terminated by a   0    To the compiler they re both char    but if you try to copy from one to the other you get in huge trouble   So  off the top of my head    char  aszFred    Hi I m a null-terminated string   char  arrWilma     O    o    p    s      where  asz  means this variable is  ascii string  zero-terminated  and  arr  means this variable is a character array   Then the magic happens   The compiler will be perfectly happy with this statement    strcpy arrWilma  aszFred     But you  as a human  can look at it and say  hey  those variables aren t really the same type  I can t do that    Unfortunately a lot places use standards such as  m   for member variables   i  for integers no matter how used   cp  for char pointers   In other words they re duplicating what the compiler knows  and making the code hard to read at the same time   I believe this pernicious practice should be outlawed by statute and subject to harsh penalties   Finally   there s two points I should mention    Judicious use of C   features allows the compiler to know the information you had to encode in raw C-style variables   You can make classes that will only allow valid operations   This should be done as much as practical  If your code blocks are so long that you forget what type a variable is before you use it  they are way too long   Don t use names  re-organize

User · Answer

I use it because VC   s Intellisense can t tell when to show private members when accessing out of the class  The only indication is a little  lock  symbol on the field icon in the Intellisense list  It just makes it easier to identify private members fields  easier  Also a habit from C  to be honest   class Person      std  string m Name  public     std  string Name     return m Name       void SetName std  string name    m Name   name        int main       Person  p   new Person      p- gt Name       valid   p- gt m Name     invalid  compiler throws error  but intellisense doesn t know this     return 1

User · Answer

Code Complete recommends m varname for member variables   While I ve never thought the m  notation useful  I would give McConnell s opinion weight in building a standard

User · Answer

As others have already said  the importance is to be colloquial  adapt naming styles and conventions to the code base in which you re writing  and to be consistent   For years I have worked on a large code base that uses both the  this-   convention as well as using a postfix underscore notation for member variables   Throughout the years I ve also worked on smaller projects  some of which did not have any sort of convention for naming member variables  and other which had differing conventions for naming member variables   Of those smaller projects  I ve consistently found those which lacked any convention to be the most difficult to jump into quickly and understand   I m very anal-retentive about naming   I will agonize over the name to be ascribed to a class or variable to the point that  if I cannot come up with something that I feel is  good   I will choose to name it something nonsensical and provide a comment describing what it really is   That way  at least the name means exactly what I intend it to mean--nothing more and nothing less   And often  after using it for a little while  I discover what the name should really be and can go back and modify or refactor appropriately   One last point on the topic of an IDE doing the work--that s all nice and good  but IDEs are  often not available in environments where I have perform the most urgent work   Sometimes the only thing available at that point is a copy of  vi    Also  I ve seen many cases where IDE code completion has propagated stupidity such as incorrect spelling in names   Thus  I prefer to not have to rely on an IDE crutch

User · Answer

I think that  if you need prefixes to distinguish class members from member function parameters and local variables  either the function is too big or the variables are badly named  If it doesn t fit on the screen so you can easily see what is what  refactor    Given that they often are declared far from where they are used  I find that naming conventions for global constants  and global variables  although IMO there s rarely ever a need to use those  make sense  But otherwise  I don t see much need    That said  I used to put an underscore at the end of all private class members  Since all my data is private  this implies members have a trailing underscore  I usually don t do this anymore in new code bases  but since  as a programmer  you mostly work with old code  I still do this a lot  I m not sure whether my tolerance for this habit comes from the fact that I used to do this always and am still doing it regularly or whether it really makes more sense than the marking of member variables

User · Answer

IMO  this is personal  I m not putting any prefixes at all  Anyway  if code is meaned to be public  I think it should better has some prefixes  so it can be more readable   Often large companies are using it s own so called  developer rules   Btw  the funniest yet smartest i saw was DRY KISS  Dont Repeat Yourself  Keep It Simple  Stupid    -

User · Answer

I prefer postfix underscores  like such   class Foo      private        int bar       public        int bar     return bar

User · Answer

I don t think one syntax has real value over another  It all boils down  like you mentionned  to uniformity across the source files   The only point where I find such rules interesting is when I need 2 things named identicaly  for example    void myFunc int index     this- gt index   index     void myFunc int index     m index   index      I use it to differentiate the two  Also when I wrap calls  like from windows Dll  RecvPacket      from the Dll might be wrapped in RecvPacket      in my code  In these particular occasions using a prefix like     might make the two look alike  easy to identify which is which  but different for the compiler

User · Answer

Lately I have been tending to prefer m  prefix instead of having no prefix at all  the reasons isn t so much that its important to flag member variables  but that it avoids ambiguity  say you have code like   void set foo int foo    foo   foo     That of cause doesn t work  only one foo allowed  So your options are    this- gt foo   foo   I don t like it  as it causes parameter shadowing  you no longer can use g   -Wshadow warnings  its also longer to type then m   You also still run into naming conflicts between variables and functions when you have a int foo  and a int foo     foo   foo   or foo   arg foo   Been using that for a while  but it makes the argument lists ugly  documentation shouldn t have do deal with name disambiguity in the implementation  Naming conflicts between variables and functions also exist here  m foo   foo   API Documentation stays clean  you don t get ambiguity between member functions and variables and its shorter to type then this- gt   Only disadvantage is that it makes POD structures ugly  but as POD structures don t suffer from the name ambiguity in the first place  one doesn t need to use it with them  Having a unique prefix also makes a few search amp replace operations easier  foo    foo   Most of the advantages of m  apply  but I reject it for aesthetic reasons  a trailing or leading underscore just makes the variable look incomplete and unbalanced  m  just looks better  Using m  is also more extendable  as you can use g  for globals and s  for statics    PS  The reason why you don t see m  in Python or Ruby is because both languages enforce the their own prefix  Ruby uses   for member variables and Python requires self

User · Answer

Our project has always used  its  as a prefix for member data  and  the  as a prefix for parameters  with no prefix for locals   It s a little cutesy  but it was adopted by the early developers of our system because they saw it used as a convention by some commercial source libraries we were using at the time  either XVT or RogueWave - maybe both    So you d get something like this   void MyClass  SetName const RWCString  amp theName       itsName   theName      The big reason I see for scoping prefixes  and no others - I hate Hungarian notation  is that it prevents you from getting into trouble by writing code where you think you re referring to one variable  but you re really referring to another variable with the same name defined in the local scope   It also avoids the problem of coming up with a variable names to represent that same concept  but with different scopes  like the example above   In that case  you would have to come up with some prefix or different name for the parameter  theName  anyway - why not make a consistent rule that applies everywhere   Just using this-  isn t really good enough - we re not as interested in reducing ambiguity as we are in reducing coding errors  and masking names with locally scoped identifiers can be a pain   Granted  some compilers may have the option to raise warnings for cases where you ve masked the name in a larger scope  but those warnings may become a nuisance if you re working with a large set of third party libraries that happen to have chosen names for unused variables that occasionally collide with your own   As for the its the itself - I honestly find it easier to type than underscores  as a touch typist  I avoid underscores whenever possible - too much stretching off the home rows   and I find it more readable than a mysterious underscore

User · Answer

You have to be careful with using a leading underscore   A leading underscore before a capital letter in a word is reserved  For example    Foo   L  are all reserved words while   foo   l  are not   There are other situations where leading underscores before lowercase letters are not allowed   In my specific case  I found the  L happened to be reserved by Visual C   2005 and the clash created some unexpected results   I am on the fence about how useful it is to mark up local variables   Here is a link about which identifiers are reserved  What are the rules about using an underscore in a C   identifier

User · Answer

In python leading double underscores are used to emulate private members  For more details see this answer

User · Answer

When you have a big method or code blocks  it s convenient to know immediately if you use a local variable or a member  it s to avoid errors and for better clearness

User · Answer

I almost never use prefixes in front of my variable names  If you re using a decent enough IDE you should be able to refactor and find references easily  I use very clear names and am not afraid of having long variable names  I ve never had trouble with scope either with this philosophy   The only time I use a prefix would be on the signature line  I ll prefix parameters to a method with   so I can program defensively around them

User · Answer

The main reason for a member prefix is to distinguish between a member function local and a member variable with the same name  This is useful if you use getters with the name of the thing   Consider   class person   public      person const std  string amp  full name            full name  full name              const std  string amp  full name   const   return full name     private      std  string full name        The member variable could not be called full name in this case  You need to rename the member function to get full name   or decorate the member variable somehow

User · Answer

I use m  for member variables just to take advantage of Intellisense and related IDE-functionality  When I m coding the implementation of a class I can type m  and see the combobox with all m  members grouped together     But I could live without m   s without problem  of course  It s just my style  of work

User · Answer

Others try to enforce using   this- member whenever a member   variable is used   That is usually because there is no prefix  The compiler needs enough information to resolve the variable in question  be it a unique name because of the prefix  or via the this keyword   So  yes  I think prefixes are still useful  I  for one  would prefer to type     to access a member rather than  this-

User · Answer

Some responses focus on refactoring  rather than naming conventions  as the way to improve readability  I don t feel that one can replace the other   I ve known programmers who are uncomfortable with using local declarations  they prefer to place all the declarations at the top of a block  as in C   so they know where to find them   I ve found that  where scoping allows for it  declaring variables where they re first used decreases the time that I spend glancing backwards to find the declarations   This is true for me even for small functions   That makes it easier for me to understand the code I m looking at   I hope it s clear enough how this relates to member naming conventions  When members are uniformly prefixed  I never have to look back at all  I know the declaration won t even be found in the source file   I m sure that I didn t start out preferring these styles  Yet over time  working in environments where they were used consistently  I optimized my thinking to take advantage of them  I think it s possible that many folks who currently feel uncomfortable with them would also come to prefer them  given consistent usage

User · Answer

I m all in favour of prefixes done well   I think  System  Hungarian notation is responsible for most of the  bad rap  that prefixes get   This notation is largely pointless in strongly typed languages e g  in C    lpsz  to tell you that your string is a long pointer to a nul terminated string  when  segmented architecture is ancient history  C   strings are by common convention pointers to nul-terminated char arrays  and it s not really all that difficult to know that  customerName  is a string   However  I do use prefixes to specify the usage of a variable  essentially  Apps Hungarian   although I prefer to avoid the term Hungarian due to it having a bad and unfair association with System Hungarian   and this is a very handy timesaving and bug-reducing approach   I use    m for members c for constants readonlys p for pointer  and pp for pointer to pointer  v for volatile s for static i for indexes and iterators e for events   Where I wish to make the type clear  I use standard suffixes  e g  List  ComboBox  etc    This makes the programmer aware of the usage of the variable whenever they see use it  Arguably the most important case is  p  for pointer  because the usage changes from var  to var-  and you have to be much more careful with pointers - NULLs  pointer arithmetic  etc   but all the others are very handy   For example  you can use the same variable name in multiple ways in a single function   here a C   example  but it applies equally to many languages   MyClass  MyClass int numItems        mNumItems   numItems      for  int iItem   0  iItem  lt  mNumItems  iItem                  Item  pItem   new Item            itemList iItem    pItem            You can see here    No confusion between member and parameter No confusion between index iterator and items Use of a set of clearly related variables  item list  pointer  and index  that avoid the many pitfalls of generic  vague  names like  count    index   Prefixes reduce typing  shorter  and work better with auto-completion  than alternatives like  itemIndex  and  itemPtr    Another great point of  iName  iterators is that I never index an array with the wrong index  and if I copy a loop inside another loop I don t have to refactor one of the loop index variables   Compare this unrealistically simple example   for  int i   0  i  lt  100  i        for  int j   0  j  lt  5  j            list i  score    other j  score     which is hard to read and often leads to use of  i  where  j  was intended   with   for  int iCompany   0  iCompany  lt  numCompanies  iCompany        for  int iUser   0  iUser  lt  numUsers  iUser           companyList iCompany  score    userList iUser  score     which is much more readable  and removes all confusion over indexing  With auto-complete in modern IDEs  this is also quick and easy to type   The next benefit is that code snippets don t require any context to be understood  I can copy two lines of code into an email or a document  and anyone reading that snippet can tell the difference between all the members  constants  pointers  indexes  etc  I don t have to add  oh  and be careful because  data  is a pointer to a pointer   because it s called  ppData    And for the same reason  I don t have to move my eyes out of a line of code in order to understand it  I don t have to search through the code to find if  data  is a local  parameter  member  or constant  I don t have to move my hand to the mouse so I can hover the pointer over  data  and then wait for a tooltip  that sometimes never appears  to pop up  So programmers can read and understand the code significantly faster  because they don t waste time searching up and down or waiting       If you don t think you waste time searching up and down to work stuff out  find some code you wrote a year ago and haven t looked at   since  Open the file and jump about half way down without reading it    See how far you can read from this point before you don t know if   something is a member  parameter or local  Now jump to another random   location    This is what we all do all day long when we are single   stepping through someone else s code or trying to understand how to   call their function    The  m  prefix also avoids the  IMHO  ugly and wordy  this-   notation  and the inconsistency that it guarantees  even if you are careful you ll usually end up with a mixture of  this- data  and  data  in the same class  because nothing enforces a consistent spelling of the name     this  notation is intended to resolve ambiguity - but why would anyone deliberately write code that can be ambiguous  Ambiguity will lead to a bug sooner or later   And in some languages  this  can t be used for static members  so you have to introduce  special cases  in your coding style  I prefer to have a single simple coding rule that applies everywhere - explicit  unambiguous and consistent   The last major benefit is with Intellisense and auto-completion  Try using Intellisense on a Windows Form to find an event - you have to scroll through hundreds of mysterious base class methods that you will never need to call to find the events  But if every event had an  e  prefix  they would automatically be listed in a group under  e   Thus  prefixing works to group the members  consts  events  etc in the intellisense list  making it much quicker and easier to find the names you want   Usually  a method might have around 20-50 values  locals  params  members  consts  events  that are accessible in its scope  But after typing the prefix  I want to use an index now  so I type  i       I am presented with only 2-5 auto-complete options  The  extra typing  people attribute to prefixes and meaningful names drastically reduces the search space and measurably accelerates development speed   I m a lazy programmer  and the above convention saves me a lot of work  I can code faster and I make far fewer mistakes because I know how every variable should be used     Arguments against  So  what are the cons  Typical arguments against prefixes are     Prefix schemes are bad evil   I agree that  m lpsz  and its ilk are poorly thought out and wholly useless  That s why I d advise using a well designed notation designed to support your requirements  rather than copying something that is inappropriate for your context   Use the right tool for the job    If I change the usage of something I have to rename it   Yes  of course you do  that s what refactoring is all about  and why IDEs have refactoring tools to do this job quickly and painlessly  Even without prefixes  changing the usage of a variable almost certainly means its name ought to be changed   Prefixes just confuse me   As does every tool until you learn how to use it  Once your brain has become used to the naming patterns  it will filter the information out automatically and you won t really mind that the prefixes are there any more  But you have to use a scheme like this solidly for a week or two before you ll really become  fluent   And that s when a lot of people look at old code and start to wonder how they ever managed without a good prefix scheme   I can just look at the code to work this stuff out   Yes  but you don t need to waste time looking elsewhere in the code or remembering every little detail of it when the answer is right on the spot your eye is already focussed on   Some of  that information can be found by just waiting for a tooltip to pop up on my variable  Yes  Where supported  for some types of prefix  when your code compiles cleanly  after a wait  you can read through a description and find the information the prefix would have conveyed instantly  I feel that the prefix is a simpler  more reliable and more efficient approach   It s more typing   Really  One whole character more  Or is it - with IDE auto-completion tools  it will often reduce typing  because each prefix character narrows the search space significantly  Press  e  and the three events in your class pop up in intellisense  Press  c  and the five constants are listed   I can use this- gt  instead of m   Well  yes  you can  But that s just a much uglier and more verbose prefix  Only it carries a far greater risk  especially in teams  because to the compiler it is optional  and therefore its usage is frequently inconsistent  m on the other hand is brief  clear  explicit and not optional  so it s much harder to make mistakes using it

User · Answer

I generally don t use a prefix for member variables   I used to use a m prefix  until someone pointed out that  C   already has a standard prefix for member access  this- gt    So that s what I use now  That is  when there is ambiguity  I add the this- gt  prefix  but usually  no ambiguity exists  and I can just refer directly to the variable name   To me  that s the best of both worlds  I have a prefix I can use when I need it  and I m free to leave it out whenever possible   Of course  the obvious counter to this is  yes  but then you can t see at a glance whether a variable is a class member or not    To which I say  so what  If you need to know that  your class probably has too much state  Or the function is too big and complicated    In practice  I ve found that this works extremely well  As an added bonus it allows me to promote a local variable to a class member  or the other way around  easily  without having to rename it   And best of all  it is consistent  I don t have to do anything special or remember any conventions to maintain consistency      By the way  you shouldn t use leading underscores for your class members  You get uncomfortably close to names that are reserved by the implementation   The standard reserves all names starting with double underscore or underscore followed by capital letter  It also reserves all names starting with a single underscore in the global namespace   So a class member with a leading underscore followed by a lower-case letter is legal  but sooner or late you re going to do the same to an identifier starting with upper-case  or otherwise break one of the above rules   So it s easier to just avoid leading underscores  Use a postfix underscore  or a m  or just m prefix if you want to encode scope in the variable name

User · Answer

According to JOINT STRIKE FIGHTER AIR VEHICLE C   CODING STANDARDS  december 2005    AV Rule 67 Public and protected data should only be used in structs   not classes  Rationale  A class is able to maintain its invariant by controlling access to its data  However  a class cannot control access to its members if those members non-private  Hence all data in a class should be private   Thus  the  quot m quot  prefix becomes unuseful as all data should be private  But it is a good habit to use the p prefix before a pointer as it is a dangerous variable

User · Answer

Many of those conventions are from a time without sophisticated editors  I would recommend using a proper IDE that allows you to color every kind of variable  Color is by far easier to spot than any prefix   If you need to get even more detail on a variable any modern IDE should be able to show it to you by moving the caret or cursor over it  And if you use a variable in a wrong way  for instance a pointer with the   operator  you will get an error  anyway

User · Answer

Those conventions are just that  Most shops use code conventions to ease code readability so anyone can easily look at a piece of code and quickly decipher between things such as public and private members

[c++] Why use prefixes on member variables in C++ classes

Examples related to c++

Examples related to coding-style

Examples related to naming-conventions