Hacker News Reader

Comment by ddevault | Hacker News Reader

>Not typedef'ing your structs forces you to use extra 7 characters per type mention for no clear benefit. To put it differently - if NOT having "struct" in front of a type name has any effect on readability/maintainability of your code, then there are deeper problems with your coding style that won't be solved by dragging "struct" around.

The benefit is to readability. You should treat structs differently from scalars, and the code should make the distinction apparent. You should not generally, for example, pass structs by value. This is just laziness.

View on HN

I doubt getting confused between structs and scalars is a problem in practice. It surely never has been for me.

For me this is cargo cult maintainability: it has the sound of a good advice, but doesn't seem grounded in reality.

Why not pass structs by value?

Of course, it is copied because "by value". On the AMD64 architecture your compiler will transfer your little structs in registers.

Not sure I follow.

> scalars

So you would typedef the scalars then? If you don't, then scalars will be the built-in types (which you'd presumably know well) and then all other type names will be typedef'ed structs/unions, still making it trivial to recognize them as such.

Yes, I think typedefing scalars is fine. Typedefs are useful for abstracting the underlying storage mechanism for a scalar (so you can i.e. change it on different archictures or in a future release without breakage), not for saving yourself 6 characters of typing.

Typedefs are useful for creating short-hand names for otherwise long or complicated type definitions. Saving 7 (6 for 'struct' + space) characters is as good use for typedef as any other.

You only have to write each set of seven characters once; yes, typing will require a bit more effort. However, we shouldn't optimize code for the ease of writing, we should be optimizing for the ease of reading. Write once, read many.

`struct foo` is a bit more instructive when understanding code than `foo`; at worst, they read the same to someone familiar to the codebase, at best they prevent the need to flip back and forth to the type definitions.

>Typedefs are useful for abstracting the underlying storage mechanism for a scalar (so you can i.e. change it on different archictures or in a future release without breakage), not for saving yourself 6 characters of typing.

You can just use stdint types. Or is it really better to typedef a CUTE_INT?

That's not what I'm talking about. CUTE_INT is stupid, but maybe mylib_error makes sense. It depends on context.

There are also enums, which are user defined scalar types (although I don't think this fact really affects your argument).

I have been writing C for more than a decade and have never been confused about whether or not a type was a strict or a scalar. This is a nonsense hypothetical.

Surely a simple naming convention such as a capital letter for compound types is sufficient?

Or something as basic as

    foo_s
    bar_u
    baz_e

for structs, unions and enums respectively. Perhaps even splurge on xyz_f for function pointers... though that's getting recklessly close to the Hungarian notation :)

I love Hungarian Notation, I mean, it's pretty intuitive that LPCTSTR is a long pointer to a (zero-terminated) constant TCHAR string.

I definitely never panicked as a kid when I saw WINAPI-related code.

Reply on news.ycombinator.com