| ||||||||||||
|
Shop the new tech.book(store)
New! Introducing the tech.book(store), a hub for Software Developers and Architects, Networking Administrators, TPMs, and other technology professionals to find highly-rated and highly-relevant career resources. Shop books on programming and big data, or read this week's blog posts by authors and thought-leaders in the tech industry. > Shop now |
Product Details
Would you like to update product info or give feedback on images? |
This book isn't a recipe book, and it's a bit dated, having been written during the days of DOS and the first Macintosh, but the underlying themes and general advice are still valid:
- Enable compiler warnings and pay attention to them.
- Use assertions to validate your assumptions.
- Don't quietly ignore error conditions or invalid input.
- For a complicated, critical algorithm, consider using a second algorithm to validate the first. (e.g. validate binary search with a linear search).
- Don't write multi-purpose functions such as realloc (it can grow memory, shrink memory, free memory, or allocate new memory -- it does it all).
- Check boundary conditions carefully.
- Avoid risky language idioms.
- Write code for the "average" programmer. Don't make the "average" programmer reach for a reference manual to understand your code.
- Fix bugs now, not later.
- There are no free features; don't allow needless flexibility (like realloc).
- Ultimately the developer is responsible for finding bugs; he shouldn't write sloppy code and hope that QA will find all his bugs.
On the other hand, the book's source language (the C programming language, as used by Microsoft tools) is increasingly outdated. This might prevent some people from appreciating the finer insights of this book. Also, the author recommends use of Hungarian notation, which I despise in a strongly typed language. (My recommendation: use PC-Lint, with strong types. Both more powerful, and more readable.) Still, the overall philosophy of the book is very powerful, and the concepts and techniques that it discusses can easily be applied to other programming languages and other software development efforts. I was writing in C++ when I read the book, and I currently program in Java, but I still apply the lessons I learned from this book.
This book is certainly not the ONLY way to write solid code (and I have found improvements on a number of techniques discussed in the book), but it does sketch out a fairly workable process which if followed would produce a quality product. Most importantly, the PHILOSOPHY that the author uses to approach writing bug-resistant programs is quite powerful.
Note that this is a book on software implementation, not software design (except in the small scale). Large-scale design is a whole separate issue which this book really does not address much.