Hacker News Reader

Comment by userbinator | Hacker News Reader

The winning entry reminds me of Linus (Torvalds)' viewpoint on typedefs: http://yarchive.net/comp/linux/typedefs.html

Those for whom the name Linus Åkesson is unfamiliar are highly encouraged to visit his site at http://www.linusakesson.net/ --- he has a lot of other interesting articles on programming and the demoscene.

View on HN

"if your typing speed is the main issue when you're coding, you're doing something seriously wrong"

So does he mean that programming/hacking is not about banging a keyboard as fast as possible?/s I wish more people knew that.

Most importantly, I wish more managers knew that.

As I understood the comment from the context, it was to chide the typedef-er for trying to save on typing by defining frivolous and obfuscating typedefs. He appears to be saying the defining a typedef to save on typing a long name is a false savings, as I understood it.

Interestingly, in our codebase at work we use completely opposite approach, but the code is C++, not C. We try everything to have its own type, so instead of "unsigned long", we would use "widget_counter_t", for example. I almost never encountered a situation, where I would need to know that widget_counter_t is actually unsigned long. And in rare case I need to know, I just hit F12 in Visual Studio and look at the type. But normally, variable type should semantically define what the variable holds, not describe the byte representation of that variable.

Is there a specific reason for using typedefs rather than (packed) structs? With typedefs you get no real type safety (you can pass a widget_counter_t to a method that expects a foo_t if both typedef to the same thing), do you?

This is probably an amateur C question, but would the typedef in the winning entry be considered good practice if you want to swap the type easily? Like being able to change to a long double if a detector with higher precision is made, or int after noticing that all incoming data are ints anyways? I'd also probably give the type more descriptive name (which breaks the beautiful bug). Or would there be a better way to handle that sort of situation?

That's a fine question to ask. Yes, using a typedef for this purpose is good practice. It's debatable if it's a good idea to add the abstraction of a typedef if you don't need the flexibility, but if you are trying to write generic code in C, a typedef like this is the best approach.

The only real alternative would be a a preprocessor define, which is even more "heavyweight". A define written in uppercase might be better if you want to signify that it's something changeable, but the typedef is probably slightly safer.

The real issue here is not the typedef, but the name choice. "float_t" is a reserved name, and it's unlikely to be a good idea to typedef a reserved name. Counter to common practice, all typenames ending with "_t" are actually reserved by Posix[1] and thus arguably should be avoided for user code.

[1] http://www.gnu.org/software/libc/manual/html_node/Reserved-N...

I'm with Linus here, typedefs in C make the code contex sensitive to parse not only for compilers but for humans too. Syntax highlighting will make `struct gadget * gadget` highlighted correctly but `gadget_t * gadget` doesn't get highlit in a typical text editor (without some kind of smart, context aware highlighting).

Reply on news.ycombinator.com