> I guess we have very different approaches to looking at new software.
> Since the structures (classes) are the skeleton
There's a book titled something like "structs + methods = programs". :)
When I'm analysing code to see how it works inside, I consider it
a flaw if I can't look through the headers and get a basic feel
for the key types and their operations. Those headers are where
the interfaces between components get defined ... or at least,
they should be. On well written and maintainable code, the headers
are very usable for such purposes. (OpenOCD isn't there yet.)
> around which openocd
> is structured it seems a bit far-fetched to me that you could go
> through the code without looking at the structs.
It's a question of how much you can do without head scratching,
and how *locally* meaningful the code is. I didn't say you can't
look at the structs ... just that you shouldn't *have* to do so
for a first reading of a function. (Which is what I always need
to do when dealing with typedef-infested code.)
There's a spectrum of how widely typedefs get used. In my book,
they only get used to solve problems that are painful without
them ... function signature templates being one of the most basic
examples, size-specific types ("uint32_t") being another. Because
I've seen way too much code that just uses typedefs willy-nilly,
without them adding any real value.
- Dave
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
