> 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.
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.