Post History

Are there technical reasons to pick one struct coding style over the other?

C offers two different styles when it comes to structs (and union/enum too). Either declare them using a struct tag only ("struct tag style"):

    struct my_type 
    { ... };

    struct my_type x;

Or by using a `typedef`, where the tag is optional ("typedef style"):

    typedef struct optional_tag
    { ... } my_type;

    my_type x;

My personal observation is that the latter style is far more common, though the former style is dominant in Linux programming (but perhaps not necessarily in older *nix programming?).

**Are there any real technical arguments in favour of one style or the other?**

---

Some mostly subjective arguments that I've heard:

- The so-called ["Linux kernel coding style"](https://www.kernel.org/doc/html/v4.10/process/coding-style.html#typedefs) rants subjectively against using `typedef` in general, using "arguments" like _"Lots of people think that typedefs help readability. Not so."_

  There may be a grain of truth in what they are trying to say here - we should't use `typedef` to come up with some home-made, "local garage standard" type system such as `typedef uint8_t my_little_uint8;` or `typedef bool boule;` - crap like that is far too common.

  But in general the document fails completely to make a case in favor of the struct tag style, which is the coding standard used in Linux. Basically the reasons for sticking to the style are 100% subjective - because some random open source dude(s) says so. Which isn't necessarily wrong in case all arguments for/against are subjective, then we just have to pick something and stick with it.

  They do manage to make one good arguments against their own style: _"totally opaque objects (where the typedef is actively used to hide what the object is)"_. This is a valid argument against the style used in Linux.

- "Save typing" is a misguided argument often used when defending all manner of more or less bad coding practices, such as coming up with strange `typedef` types. This is a poor argument, because 1) programming is _all about typing_ - those who have a problem with it should consider a different trade, and 2) copy/paste has been available since the dawn of time, as has the pro tip ctrl+shift+left/right arrow key - who cares how long the words are, and 3) various forms of code completion is nowadays supported by all programming IDEs at some extent.

- "Everyone hates Hungarian notation". That is, the type system which Windows has used internally since the first version, where you would name types so that it would be clear what underlying type is. `LPVOID` would mean "long pointer to void", essentially just a `void*`. The Linux side of things are happy to jump on the bandwagon and rant against this style too, and yet they preach "struct tag style" for the very same reasons - to explicitly make it clear what lies underneath a certain type.

  Today you can just hit a shortcut in your IDE and land in the struct/`typedef`, so the need for creative naming like this was perhaps more of a thing in the past when coding in raw text editors with no C awareness.

None of these arguments are all that convincing for one style over the other.