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.
It's best to keep the code in everything to the minimum!
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.
Thanks for saying this... it needs to be said far more often.
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 prefer the term "maintainability" to "readability", and I completely agree with you there.
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 definitely agree with that. I was thinking of minimal code as a way to achieve the ends of readability and maintainability. Excessive minimalism goes against both of those goals, when you get to compactness for the sake of compactness, perl code golf or micro optimization style.
Yeah, I remember reading somewhere that they have extremely strict standards at NASA, to the point that multiple reviews are mandatory on even single line changes for mission critical systems.
Yeah, that's the best example I could come up with at the time of writing the comment. It's been a long day today, and I don't mind the nit-pick, you are right.
Comments
While I completely agree with you in general, a nit pick:
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.
It's best to keep the code in everything to the minimum!
True!
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.
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.
Thanks for saying this... it needs to be said far more often.
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 prefer the term "maintainability" to "readability", and I completely agree with you there.
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 definitely agree with that. I was thinking of minimal code as a way to achieve the ends of readability and maintainability. Excessive minimalism goes against both of those goals, when you get to compactness for the sake of compactness, perl code golf or micro optimization style.
Yeah, I remember reading somewhere that they have extremely strict standards at NASA, to the point that multiple reviews are mandatory on even single line changes for mission critical systems.
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.
Yeah, that's the best example I could come up with at the time of writing the comment. It's been a long day today, and I don't mind the nit-pick, you are right.