Software design book recommendations

[genericpurpleturtle]

Hello all! First of all I apologise if this isn't quite in the right subsection of the forum, I didn't really know where it should go and this seemed the most fitting.

I am a junior embedded software engineer and at work we have some extra money in the "consumables" budget and it has been suggested that it be spent on books. As well as getting the newest edition of the Art of Electronics by Horowitz, I was thinking it may be worth also getting some books on software design. I did Electronics at university and we hardly did any programming and any programming I have done has been mostly self taught and as such I do not doubt that I have a lot of bad habits in the way I structure my code, so a book that covers good design principles for C I think would be helpful.

I've found a book on C compilers called Advanced C and C++ Compiling by Stevanovic, which I may purchase as I think I could definitely develop my understanding of whole compilers work also. If anyone has any other book recommendations of this nature, or essentially any aspect of embedded software engineering or even software engineering more generally it would be most helpful.

Cheers!

[vidi]

1. Clean code by Robert C. Martin
The examples are dedicated to Java, but the same principles/rules can be applied also on application in embedded programming (unless you want to do some really low level stuff like kernel optimization, DMA drivers, ...)

2. Design Patterns: Elements of Reusable Object-Oriented Software
Might be obsolete these days, but it was really handy to understand high abstraction levels.

3. Modern C++ Design by Andrei Alexandrescu
Dedicated to uncommon C++ techniques and hidden features, mainly related to meta programming. It is also quite old now.

4. Art of computer programming by Knuth.
Bible of algorithm analysis.

[legacy]

Writing Solid Code, Microsoft Techniques
It shows interesting points

[mac.6]

Mastering regular expressions
http://shop.oreilly.com/product/9780596528126.do

Not directly related to embedded sw, but a must for dev tasks, especially when you do not spend time doing regexp

[Dielectric]

If you're relatively new, Elecia White's book would be good:
http://shop.oreilly.com/product/0636920017776.do

[andyturk]

A great book about embedded projects is Better Embedded System Software by Philip Koopman.

It's not really about programming, but has tons of insights and suggestions about embedded projects and what makes the good ones go smoothly.

[agehall]

Mastering regular expressions
http://shop.oreilly.com/product/9780596528126.do

Not directly related to embedded sw, but a must for dev tasks, especially when you do not spend time doing regexp

OT: RegExps should die. Period. They are the horror of all code and the cause of many many many problems. I know several languages encourage the use of them but honestly, the number of times I've actually had to resort to RegExps can be counted on the fingers of my hands. There are usually much better ways of solving problems.

[Kalvin]

Mastering regular expressions
http://shop.oreilly.com/product/9780596528126.do

Not directly related to embedded sw, but a must for dev tasks, especially when you do not spend time doing regexp

OT: RegExps should die. Period. They are the horror of all code and the cause of many many many problems. I know several languages encourage the use of them but honestly, the number of times I've actually had to resort to RegExps can be counted on the fingers of my hands. There are usually much better ways of solving problems.

Regexp syntax is quite horrifying and errorprone, and getting the expression right will take some iteration and testing. Maintaining the regexp expressions is not for faint hearted either. There is nothing wrong with the regular expressions per se, as they are very powerful tool in right hands.

[Doctorandus_P]

I think that people who are interested in writing good / decent code already write a lot better code than the people who do not even think about code quality, so kudo's for the interest in this topic.
I once wasted a few hours analizing the initialisaton routines of a small uC  divided over a lot of functions  which essentially did almost nothing, and should have been 10 or so straight forward lines of code.

Basic code design principles are partly agnostic of the programming language used, but it still helps if you study a book for the same programming language you're interested in. I know some  C ( and a bit less fluently with C++). With C++ you can & should initialize data in the constructor of a class, while in C classes don't exist and stuff is initialized where declared, or in a separate function.

Therefore  my choice for book suggestions would be from the books recommended by the C++ standards committee:
[url][https://isocpp.org/search/google?q=book/url]

[Kalvin]

I have found the following books quite useful for embedded systems design and implementation:

Patterns for Time-Triggered Embedded Systems by Michael J. Pont:
https://www.safetty.net/publications/pttes

Never mind if the book is not targeted your particular microcontroller. The patterns are the meat of the book.

Test Driven Development for Embedded C (Pragmatic Programmers):
https://www.amazon.com/Driven-Development-Embedded-Pragmatic-Programmers/dp/193435662X

Practical UML Statecharts in C/C++: Event-Driven Programming for Embedded Systems
https://www.amazon.com/Practical-UML-Statecharts-Event-Driven-Programming/dp/0750687061

Somewhat useful stuff also in here:

Making Embedded Systems: Design Patterns for Great Software
https://www.amazon.com/Making-Embedded-Systems-Patterns-Software/dp/1449302149

[Leiothrix]

OT: RegExps should die. Period. They are the horror of all code and the cause of many many many problems. I know several languages encourage the use of them but honestly, the number of times I've actually had to resort to RegExps can be counted on the fingers of my hands. There are usually much better ways of solving problems.

Regexs are the best way of doing the things that regexs do.  If you haven't had the need to use them that means probably haven't had to do much in the way of string processing.

Edit:  I'm talking about full-size computers here, embedded is different, especially the smaller devices.

[RoGeorge]

"Head First - Design Patterns"

[Jeroen3]

1. Clean code by Robert C. Martin
The examples are dedicated to Java, but the same principles/rules can be applied also on application in embedded programming (unless you want to do some really low level stuff like kernel optimization, DMA drivers, ...)

It's not specifically only java. It's object oriented programming. I read it last month, SOLID book, can definitely recommended.

The thing is, you can read these architecture books by software guru's but they will go against each other on several fronts. Don't use them as bible. Use then for inspiration.

[Richard Crowley]

The Mythical Man-Month: Essays on Software Engineering by Frederick P. Brooks Jr.

Mr. Brooks was the project manager for the landmark IBM System/360 computer family and then for its massive operating system: OS/360.

Key things that have been of benefit to me for 30 years include:

Brooks' Law: "Adding manpower to a late software project makes it later."

The "Second System Effect" where you commonly over-engineer the system.  Some recommend simply throwing out Rev.2 altogether.

The "Surgical Team" of seven key members (ideally individuals) of a development team. Alas, I usually work on projects where I am all (or most) of these seven roles.  Nevertheless, it is good to remember the division of labor and different expertise and contributions to the project.

The full text of the book is available online at:
https://archive.org/stream/mythicalmanmonth00fred/mythicalmanmonth00fred_djvu.txt

And a good summary at: https://en.wikipedia.org/wiki/The_Mythical_Man-Month

[RoGeorge]

1. Clean code by Robert C. Martin

I read that book and didn't like it. It's more of a fashion title, I guess, because some advises are straight wrong IMO, like e.g. "don't comment your code" - which is a very bad idea. Not all code is obvious, or self explanatory, by classes' names.

Anyway, if you want to know the rules that book is pleading for, you don't need to read the whole book. It will be a waste of time. There is a page (or a very small chapter - I don't recall exactly) at the end of that book, where all the rules are simply enumerated. The name of each rule is self-explanatory, but don't follow them blindly. Some of them doesn't always makes sense.

Read only that page/chapter, and you'll know it all.

[genericpurpleturtle]

1. Clean code by Robert C. Martin

I read that book and didn't like it. It's more of a fashion title, I guess, because some advises are straight wrong IMO, like e.g. "don't comment your code" - which is a very bad idea. Not all code is obvious, or self explanatory, by classes' names.

Anyway, if you want to know the rules that book is pleading for, you don't need to read the whole book. It will be a waste of time. There is a page (or a very small chapter - I don't recall exactly) at the end of that book, where all the rules are simply enumerated. The name of each rule is self-explanatory, but don't follow them blindly. Some of them doesn't always makes sense.

Read only that page/chapter, and you'll know it all.

Yeah refusing to comment code is a pretty silly practice. Thanks for the warning.

[NorthGuy]

Yeah refusing to comment code is a pretty silly practice. Thanks for the warning.

Most "advisers" would recommend heavy commenting beyond reason. To the point that there are people who believe that "proper" commenting is more important than the code itself. When someone recommends less comments, it's rather refreshing.

[splin]

You have to wonder how much time these 'gurus' spend actually doing real development and programming as they appear to have full time careers writing, consulting and promoting their pet analysis/design/programming systems.

[nfmax]

Here's a couple to look at:

Henry Ledgard, Professional Software, Addison-Wesley 1987
Volume I - Software Engineering Concepts, ISBN 0-201-12231-6
Volume II - Programming Practice, ISBN 0-201-12232-4

Ledgard was one of the designers of MULTICS. The emphasis is on software quality & professionalism. Quite thin, but every page is worth study.

Brian W. Kernighan & Rob Pike, The Practice of Programming, Addison-Wesley 1999, ISBN 0-201-61586-X

Oddly enough, this feels a bit more dated now than Ledgard, but it has some good stuff.

[Bassman59]

Yeah refusing to comment code is a pretty silly practice. Thanks for the warning.

Most "advisers" would recommend heavy commenting beyond reason. To the point that there are people who believe that "proper" commenting is more important than the code itself. When someone recommends less comments, it's rather refreshing.

The code itself tells the reader what it is doing. The name of a variable or signal tell the reader its purpose.

Comments tell the reader why the code was written as it was, especially if the why is non-obvious.

[genericpurpleturtle]

Okay so this is the complete list of books we purchased. Any more recommendations would still be welcome, for anyone stumbling across this thread in the future. Thank you to everyone who recommended stuff. Who knows when they'll get read, but when they do, I'll try to let you guys know how useful I found them.

Advanced C and C++ Compiling

Test Driven Development for Embedded C

Practical UML Statecharts in C/C++: Event-Driven Programming for Embedded Systems
   
Making Embedded Systems: Design Patterns for Great Software

The Art of Computer Programming Volume 1: Fundamental Algorithms

Modern C++ Design: Generic Programming and Design Patterns Applied

We also got some electronics ones too.

The Art of Electronics

Microelectronic Circuits: Theory and Application

Practical Electronics for Inventors

[RoGeorge]

Beware of TDD cult, either! (Test Driven Development)

In theory, it should work very well, it seems to make sense, and it's seductive. In practice, you'll end up spending most of the time maintaining the tests and the testing infrastructure, instead of actually developing your product.

There might be situations where TDD becomes advantageous, I don't know, but in my experience it was the other way around: Overall, TDD was a major drawback and a huge time sink with no visible advantages.

[Jeroen3]

In practice, you'll end up spending most of the time maintaining the tests and the testing infrastructure, instead of actually developing your product.

Isn't that the entire point of TDD?

[vidi]

I read that book and didn't like it. It's more of a fashion title, I guess, because some advises are straight wrong IMO, like e.g. "don't comment your code" - which is a very bad idea. Not all code is obvious, or self explanatory, by classes' names.

You are taking "don't comment your code" out of context. This rule is tied with "a function do just one job" and "keep your functions small". By my C# lecturer, function should has no more than 15 lines of code - otherwise the design is wrong. So, right question to ask is - Cannot be a single purpose function, 15 lines max, written the way that you know what does it do on first sight ?

Obviously this rule does not make sense in area of cryptography, hard-core math algorithms, black-magic hardware workarounds, compiler optimization, ...
but it does for cca 95% of common code.

[andyturk]

By my C# lecturer, function should has no more than 15 lines of code - otherwise the design is wrong.

That's kind of a silly "rule" too, but the intent is reasonable. Another way to think about how to decompose your problem into smaller functions is to consider how you'll test the code. You do test, right? 

If a chunk of code is doing all kinds of different things, writing a test harness for it will be a lot of work. But if your code really is a function in the math sense, it will probably have only a few lines and be easy to test.

The codebase I'm working with now has a couple of C functions that are 1000+ lines of source. One of them compiles into about 17k of machine code.