Naming convention when using STRUCT in C

Question

I'm learning C and find someone defined a struct, its struct name has _ in front of it. This is my first time seen it, can someone tell me a little bit more about it? Why someone would use _aStructName instead of aStructName, what are the benefits?

struct _huffmanNode {
    int value;
    uint32_t frequency;

    int hasChild;
    struct _huffmanNode *child[2];

    struct _huffmanNode *next;
};

similarly I find someone using this kind of naming convention in the following code:

typedef struct HuffCode_ {

unsigned char      used;
unsigned short     code;
unsigned char      size;

} HuffCode;

Solution 1

There is no benefit in user code, it's just ugly. In the second example, the HuffCode_ isn't even necessary since the struct type is already named by the typedef.

The only places where this can be useful are:

1. When StructName is already in use, StructName_ gives a different name (but you should really come up with a better name).
2. Identifiers in the C standard library that are not defined by the standard shouldn't conflict with user code identifiers. Therefore, C library writers use the _ prefix in the hopes that users will not use that. Unfortunately, some users do.
3. In very old compilers, it may be useful to give the struct a different name than is used in the typedef. You need both the typedef and the other name if you're building a linked structure (example).

Solution 2

I think this is done mostly because of the very mistaken idea that a struct and a type cannot have the same name. In other words, that somehow

struct MyStruct;
typedef struct MyStruct MyStruct;

will collide in strange ways because the struct and the typedef have the same name. This is wrong in C. The name of a struct is considered a tag, whereas a typedef creates a type name. These live in two different namespaces and will not collide. In my opinion, it makes a lot more sense for the tag of the struct to be the same as the typedef, assuming you use a typedef at all. In C, you must always reference a struct with the struct keyword. For example, if you define

struct MyStruct;

but do not make a typedef, then the following is invalid:

void myfunction()
{
  MyStruct var;   /* compiler error: MyStruct is not defined. */
  struct MyStruct var2; /* this is OK, MyStruct is a valid name for a struct. */
}

If you want to define variables (or arguments) of type MyStruct in C, you must provide a typedef:

typedef struct MyStruct MyStruct;

void myfunction2()
{
  MyStruct var;  /* this is ok now */
  struct MyStruct var2; /* this is still ok too */
}

In this second example, var, and var2 have the same type, although this isn't obvious. Indeed, if the typedef were changed, they would no longer have the same type. Beware of this! It can cause some interesting bugs if type definitions change.

In C++, a struct definition essentially creates an implicit typedef so that both of the above code snippets compile. There is, in C++, essentially no difference between a struct name (or tag) and a type name. Which is, in my opinion, another great reason to name the two the same way, especially if you anticipate that your C module might be used by some C++ code at some point.

Solution 3

A lot of the time in straight C, people like to typedef their structs so that they don't look so ugly. So they name the struct itself something ugly, and the typedef something clean. Usually the convention I've seen in the GNU world is:

typedef struct mytype_t
{
    int field;
    char field2;
} mytype;

Solution 4

I use a variant of the second example:

typedef struct huffcode {
... } HuffCode;

View more solutions

Comments

[pmg]

Note that all identifiers that begin with an underscore are reserved for the implementation and should not be used for your own identifiers.

[Shahbaz]

@pmg: All identifiers that begin with two underscores are reserved for implementation. All identifiers that begin with one underscore should not be visible outside the file scope (for example a static global or an internal struct)

[David Titarenco]

Some people do it for (perhaps misled?) organizational purposes.

[Fred Foo]

They should just omit the name, or give it the same name as the typedef. The _t convention isn't uglifying, it's to denote that something is a type. (I've seen typedef struct foo {...} foo_t much more often.)

[Jeremy West]

Maybe worth mentioning that POSIX claims to own types with suffix *_t.

[MaxC]

and also is worthy to mention that Linux kernel coding style tells that is a "mistake" to typedef structs and pointers just to hide their nature and it is far cleaner to avoid such typedef-ing. (source here, § 5: lxr.linux.no/linux+v4.15.14/Documentation/process/…)