> I bet not even mission-critical code written to power NASA spacecraft and satellites are anywhere near that length.
That doesn't seem like a good example. You want to keep the code in those kinds of things to a minimum, and that's probably not too hard.
Optimizing for readability is usually most important.
Readability is usually more important than reusability, in fact, although readability very often enables reusability.
But we're talking about mission-critical embedded code, which is a special case in many respects. Still, making it as readable as possible makes bugs easier to find.
Reuse is an emergent property of code, though. It's very tough to engineer for reuse upfront and have that effort be successful. It's best to keep your code simple and put your effort into making it well-tested. Then, over time spot the commonalities in everyone's code, and factor out the common bits to become reusable code if everyone agrees it's worth it to do so.
I wish there were a book about how to READ software. (If anyone knows of one, please speak up.)
One tip I picked up on my own over time is when you're looking at an unfamiliar project, don't read the code like a book, read it like a program. In other words, try to find main() and trace how things work from the bottom up, rather than trying to understand it based on how the authors have broken up the code into directories. I don't know yet whether this is truly good advice.
I guess I also suspect that the code for satellites and space shuttles can be kept reasonably compact. I mean, these systems are (ideally) not designed to be everything for everybody, unlike Linux or Windows or KDE or Visual Studio or Firefox or what have you.
Here's an example: http://spinroot.com/gerard/pdf/P10.pdf
And another: http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf
Dunno how closely these are followed in day-to-day operations, but they clearly put some thought into it.