Commonly Accepted Variable Name Formatting - C/C++

I realize that this can be a matter of preference, but I have noticed that variables names in a lot of code samples I've开发者_如何学运维 seen have a prefix of g_, s_, m_, or just _. Is this a commonly accepted practice, and what do these prefixes mean? Are there any others that would be good to know?

• g_ is a global variable
• s_ is a static
• m_ is a member (an instance variable)
• _ is either a member, or more specifically a private member (both usages turn up)

This is common enough that many developers know about it, although it is not (to my knowledge) universally accepted. I don't think you are missing any others.

Update: Integrating comments below for better visibility

• _ can also be used to denote a local variable (this one really isn't "standard")
• k can be used to denote a constant

Beware the leading underscore; the C standard reserves names beginning with an underscore and various other combinations. ISO/IEC 9899:1999 (aka C99 standard) says:

§7.1.3 Reserved identifiers

Each header declares or defines all identifiers listed in its associated subclause, and optionally declares or defines identifiers listed in its associated future library directions subclause and identifiers which are always reserved either for any use or for use as file scope identifiers.

— All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.

— All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces.

— Each macro name in any of the following subclauses (including the future library directions) is reserved for use as specified if any of its associated headers is included; unless explicitly stated otherwise (see 7.1.4).

— All identifiers with external linkage in any of the following subclauses (including the future library directions) are always reserved for use as identifiers with external linkage.¹⁵⁴⁾

— Each identifier with file scope listed in any of the following subclauses (including the future library directions) is reserved for use as a macro name and as an identifier with file scope in the same name space if any of its associated headers is included.

No other identifiers are reserved. If the program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved identifier as a macro name, the behavior is undefined.

¹⁵⁴⁾ The list of reserved identifiers with external linkage includes errno, math_errhandling, setjmp, and va_end.

The rules are complicated enough that it is simpler to go with:

• Do not start identifiers with an underscore

POSIX Reserved Identifier Conventions

Also beware of using the '_t' suffix for type names, especially in a POSIX environment. Actually, the rules on the linked page are more extensive than the rules in the C99 standard, but one line says "ANY HEADER suffix '_t'". That means that if you include any POSIX header in a POSIX environment - remembering that <stdio.h> is a POSIX header as well as a standard C header - then you should not have any typedefs which end in _t such as:

C:

typedef struct data_t { ... } data_t;  // Usurping POSIX namespace

C++:

struct data_t { ... };  // Usurping POSIX namespace

There are many other 'reserved namespace' rules in POSIX - see the linked page. This is one that is commonly flouted (but it has periodically hurt the project I work on because it ignores this rule - I don't get to set all the rules, sadly).

People sometimes use "g_" where they actually mean "f_", i.e. a file scope variable.

Aside from a lone underscore prefix (e.g. _foo) this is just very ugly style. Using the lone underscore usually results in undefined behavior.

I personally find this practice totally unnecessary and in certain ways abhorrent. If you are using a decent IDE, you should not need any of this.