Philip Koopman - Better Embedded System Software Review

  Hello there!
  This post is a review of Philip's book - Better Embedded System Software. I was looking for a book where I could learn a little more about the processes of making an embedded system project or how improve my designs, improve the management of my projects, etc. I wasn't looking for something big or "complicated" as PMBOK, so I found this wonderful book.
  Although the word Software in its title, you can use most of all suggestions to your hardware design too.




 

The book covers the following topics: system development plan,  requirements,  architecture,  design,  implementation and test plans. For every topic the author give us the bad symptoms if we are not doing a good job or doing in an incorrectly manner, the risks if we continue doing in that way, how to improve or correct our management and the pitfalls to follow his suggestions. Everything with lots of good practices and good ideas.
  I think that this book is intend for people who has already a good background in development and want to improve a little more in project management. Once I mainly worked in small and medium companies, I always notice that in those companies we weren't very organized or they didn't have a methodical approach to design and that was the cause of many problems and bugs that could be solved before they happened.
  At the beginning I though that this book was a little expensive but after reading it I realized that it worth every penny payed.


  Marcelo

Read more ►

Michael Barr - Embedded C Coding Standard - Review

  Hello there!
  This post is a review of Michael Barr's Embedded C Coding Standard book.
  First of all, why a c coding standard? I have been working in my life in small and medium companies and in most of them, we always had the same problem. No c coding standard. Everyone had their own standard and very often, those standard are not standard, because it used to change every project. Every time some one quit the company, it's always the same problem: code badly written, no comments, hard to read, hard to understand and overall hard to maintain.
  So this book is a very good start point for those who works in a company which doesn't have a standard and want to deploy one.
  First Michael Barr make clear that the code written is a property of the company and not of the programmer. A standard code eliminates conflict over items that are sometimes viewed as personal stylistic preferences.
  Yet, a standard can prevent some bugs because it forces a programmer to follow some good practices that people normally doesn't do, like always open and close braces, even in a if with only one statement.
  Indeed, this book shows some goods practices like:

1. Never leave a code with comments. We should comment code with #if 0
2. Use inline functions instead of macros
3. Always use parentheses and don't rely in C's operator precedence
4. Use of doxygen to document code
5. Create the comments before begins to code once we have to know what the functions must do before start coding.

  Of course there are some suggestions that I'm not agree like:

• Use only 80 columns for code

  I think that nowadays we have big screens and the IDE is much better than before, so I don't see any problem in use more than 80 columns.

• Use goto, continue or break.

I understand that the use of this keywords can lead to "spaguetti" code, but if you really  know what are you doing, I don't think that you'll have problems.

  We can always adapt this standard. The most important thing is to have one and follow it. For sure it will save you several hours of debugging and it will improve your code quality.

  Marcelo

Read more ►