4 ms·
The way I read it, the author is surprised that struct node_t is typedef'd to node_t* and not simply node_t I am not used to that style so it seems odd to me,
by mediocrejoker 8y ago
The way I read it, the author is surprised that struct node_t is typedef'd to node_t* and not simply node_t
I am not used to that style so it seems odd to me, but I suppose if it was common in a codebase one would get used to it.
- convivialdingo 8y agoMost compilers in the 80’s and 90s had pretty restricted grammars based on K&R before C89 and newer standards fixed these sort of things. I’ve seen a bit of code like this from then... Off the top of my head, I’m thinking the Amiga toolkit and Xwindows. Old embedded code may still have some of this going on as well.
- foobiekr 8y agoSometimes limits are good. They lead to people playing it safe. I've spent most of my life dealing with C code dating from 1986 and earlier to present day. Once you get used to the stylistic conventions one of the things that falls out is the simplicity even for huge, old legacy code bases. Often little more than grep or etags is sufficient to competently navigate and follow the flow of this kind of code. Simple things are simple: what callstacks can end up here? etc. The code often has the property that if you printed it you'd still be able to navigate it without issue. Given a random page and a line, getting to somewhere would be possible. In comparison so many modern code bases are just completely incomprehensible without a tool in the form of an IDE (and often still quite challenging with them because even the IDE isn't sure, and so you must resort to runtime analysis). So many "tricks" used which require tools and require the tools to be bug free and robust. The closest I have come to "pick it up and you can read and understand it without assistive technologies" is Go.