4 out of 5 stars.
This is an MS(!) Press book written by Steve Maguire in the early 90s. Why am I reading it now? Jim Weirich (of Rake fame) recommended this book in an online video that I happened to watch.
The book was targeted at teams working in C ( distilled from the authors stint at Microsoft )... but the advice is pretty relevant even today if you can breeze through the code snippets. It seems to be out of print but you might luck out and find an old copy like I did
- Lean on the compiler.. turn on all the warnings by default. Disabling should be the exception not the rule.
- Use SCA tools from Day1. Fix issues regularly instead of letting them pile up.
- If you have unit tests, use them.
- Maintain a fortified debug version of your product with 'dev/debug mode asserts'. Conditionally compiled so that release version is lean.
- Use asserts to identify 'things that should not happen' as early as possible. (Of course tests are much better :)
- Reviewing the code (personally at least) before committing changes is the easiest and cheapest way to reduce bugs.
Design
- Don't create 'candy machine interfaces' - make it hard for clients to make mistakes.
- Eliminate 'undefined' behavior.. so that clients do not depend on it
- Don't bury error codes in return values - make them hard to ignore
- A function should do only ONE thing and do it well - (actually I rephrased it. this line's from Clean Code)
- Don't use flag arguments.
- Do not tradeoff client code readability over ease of implementation.. make code legible at point of call.
- Avoid sharing/Passing around global data
- Don't tradeoff global or algorithmic efficiency for local efficiency
- If you have to look it up, it isn't obvious. Make it boring and obvious.
- Eliminate as many if branches as possible.
- Write code for the "average" programmer. Simple over clever.
Attitude (IMO The best section of the book)
- Bugs just don't go away.. track them down.
- Fix bugs now.. not later
- Don't meddle with legacy code if you don't need to
- Don't add features if you don't need to. All flexibility has a cost. (maintenance, testing, learning curve, etc.)
- Don't keep trying solutions till one works. Take the time to find the correct one. Don't TRY.. READ.
- Don't rely on testers to find your bugs. Don't shoot the messenger when they do find your bugs
- Never allow the same bug to bite you twice. Fix your process to stonewall that type of bug.
The book has aged quite well over 20 years. Combined with on topic anecdotes (multicoloured screwdrivers is a keeper), this one is a good book to casually read while you wait for something to complete/load.
Note: The highlighted sections indicate Steve was agile before it became cool/a buzzword.
Note: The highlighted sections indicate Steve was agile before it became cool/a buzzword.