Software design book recommendations - Page 1
Forum section: electronics / general

author: genericpurpleturtle
author_rank: Contributor
timestamp: August 06, 2018, 10:07:54 am
content: 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!

author: vidi
author_rank: Contributor
timestamp: August 06, 2018, 01:28:21 pm
content: 1. Clean code by Robert C. MartinThe 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 SoftwareMight be obsolete these days, but it was really handy to understand high abstraction levels.3. Modern C++ Design by Andrei AlexandrescuDedicated 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.

author: legacy
author_rank: Super Contributor
timestamp: August 06, 2018, 02:38:40 pm
content: Writing Solid Code, Microsoft TechniquesIt shows interesting points

author: mac.6
author_rank: Regular Contributor
timestamp: August 06, 2018, 07:02:16 pm
content: Mastering regular expressionshttp://shop.oreilly.com/product/9780596528126.doNot directly related to embedded sw, but a must for dev tasks, especially when you do not spend time doing regexp

author: Dielectric
author_rank: Regular Contributor
timestamp: August 06, 2018, 07:10:56 pm
content: If you're relatively new, Elecia White's book would be good:http://shop.oreilly.com/product/0636920017776.do

author: andyturk
author_rank: Frequent Contributor
timestamp: August 07, 2018, 03:29:53 am
content: A great book about embedded projects isBetter Embedded System Softwareby 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.

author: agehall
author_rank: Frequent Contributor
timestamp: August 07, 2018, 10:39:25 am
content: Quote from: mac.6 on August 06, 2018, 07:02:16 pmOT: 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.

author: Kalvin
author_rank: Super Contributor
timestamp: August 07, 2018, 11:38:41 am
content: Quote from: agehall on August 07, 2018, 10:39:25 amRegexp 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.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: August 09, 2018, 11:59:29 am
content: 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:[https://isocpp.org/search/google?q=book/url]

author: Kalvin
author_rank: Super Contributor
timestamp: August 09, 2018, 01:54:49 pm
content: 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/pttesNever 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/193435662XPractical UML Statecharts in C/C++: Event-Driven Programming for Embedded Systemshttps://www.amazon.com/Practical-UML-Statecharts-Event-Driven-Programming/dp/0750687061Somewhat useful stuff also in here:Making Embedded Systems: Design Patterns for Great Softwarehttps://www.amazon.com/Making-Embedded-Systems-Patterns-Software/dp/1449302149

author: Leiothrix
author_rank: Regular Contributor
timestamp: August 10, 2018, 03:28:53 am
content: Quote from: agehall on August 07, 2018, 10:39:25 amRegexs 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.

author: RoGeorge
author_rank: Super Contributor
timestamp: August 10, 2018, 03:38:50 am
content: "Head First - Design Patterns"

author: Jeroen3
author_rank: Super Contributor
timestamp: August 10, 2018, 05:47:02 am
content: Quote from: vidi on August 06, 2018, 01:28:21 pmIt'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.

author: Richard Crowley
author_rank: Super Contributor
timestamp: August 10, 2018, 06:36:22 am
content: 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.txtAnd a good summary at:https://en.wikipedia.org/wiki/The_Mythical_Man-Month

author: RoGeorge
author_rank: Super Contributor
timestamp: August 10, 2018, 09:41:45 am
content: Quote from: vidi on August 06, 2018, 01:28:21 pmI 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.

author: genericpurpleturtle
author_rank: Contributor
timestamp: August 10, 2018, 03:43:40 pm
content: Quote from: RoGeorge on August 10, 2018, 09:41:45 amYeah refusing to comment code is a pretty silly practice. Thanks for the warning.

author: NorthGuy
author_rank: Super Contributor
timestamp: August 10, 2018, 04:56:58 pm
content: Quote from: genericpurpleturtle on August 10, 2018, 03:43:40 pmMost "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.

author: splin
author_rank: Frequent Contributor
timestamp: August 10, 2018, 05:04:28 pm
content: 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.

author: nfmax
author_rank: Super Contributor
timestamp: August 10, 2018, 05:23:19 pm
content: Here's a couple to look at:Henry Ledgard,Professional Software, Addison-Wesley 1987Volume I - Software Engineering Concepts, ISBN 0-201-12231-6Volume II - Programming Practice, ISBN 0-201-12232-4Ledgard 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-XOddly enough, this feels a bit more dated now than Ledgard, but it has some good stuff.

author: Bassman59
author_rank: Super Contributor
timestamp: August 10, 2018, 06:49:37 pm
content: Quote from: NorthGuy on August 10, 2018, 04:56:58 pmThe code itself tells the readerwhatit is doing. The name of a variable or signal tell the reader its purpose.Comments tell the readerwhythe code was written as it was, especially if the why is non-obvious.

author: genericpurpleturtle
author_rank: Contributor
timestamp: August 14, 2018, 09:23:01 am
content: 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++ CompilingTest Driven Development for Embedded CPractical UML Statecharts in C/C++: Event-Driven Programming for Embedded SystemsMaking Embedded Systems: Design Patterns for Great SoftwareThe Art of Computer Programming Volume 1: Fundamental AlgorithmsModern C++ Design: Generic Programming and Design Patterns AppliedWe also got some electronics ones too.The Art of ElectronicsMicroelectronic Circuits: Theory and ApplicationPractical Electronics for Inventors

author: RoGeorge
author_rank: Super Contributor
timestamp: August 14, 2018, 09:54:32 am
content: 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.

author: Jeroen3
author_rank: Super Contributor
timestamp: August 14, 2018, 11:24:38 am
content: Quote from: RoGeorge on August 14, 2018, 09:54:32 amIsn't that the entire point of TDD?

author: vidi
author_rank: Contributor
timestamp: August 14, 2018, 03:54:47 pm
content: QuoteYou 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.

author: andyturk
author_rank: Frequent Contributor
timestamp: August 14, 2018, 05:11:44 pm
content: Quote from: vidi on August 14, 2018, 03:54:47 pmThat'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 afunction 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.

author: Richard Crowley
author_rank: Super Contributor
timestamp: August 14, 2018, 05:56:09 pm
content: Quote from: RoGeorge on August 14, 2018, 09:54:32 amNot a support of TDD, but it reminds me of the "Surgical Team" in Brooks: Mythical Man-Month In that book he outlines this concept attributed to Marlan Mills:QuoteThat was back several decades ago and the roles of secretaries and program clerks and even editor have been automated in the form of word processing, spell (and grammar) checking, version management systems, etc.But the recognition of specialty people (or at least identifable tasks) like Toolsmith, Tester, and Language Lawyer have continued to be valuable concepts in my career.

author: nfmax
author_rank: Super Contributor
timestamp: August 14, 2018, 06:03:38 pm
content: Note the tester writes the specifications for the tests based on the Chief Programmer's (edited) documentation. This ensures thedocumentationis tested too.